LiveCode Forums.

Hey all, I'm back tackling a new utility in LC 10.

I notice behaviors seem to have changed in how they are assigned, and used?

Are behaviors in external stacks still the recommended approach for scripting? The new system seems to imply a single stack script per object - am I inferring that correctly?

All the help I've seen still seems to indicate the use of buttons on cards in external stacks, yet the property inspector seems to only point to "script stacks".

All of this seems to indicate a (possibly new?) general structural approach to LC app design that I'm not clear on, and isn't clearly indicated in the stuff I've seen written (legacy help files). Should I have a whole bunch of external script-only stacks to manage my code now? Is there a recommended pattern?

Has this been written about somewhere that I haven't yet found? Thanks for any pointers.

Troy.

I do not really know, but cannot imagine this is true. It would break many existing stacks, and LC would not do that.

I think.

Craig

LC would not do that

I am glad you are sure of that.

Richmond.

I did not say "did not do that", I said "would not do that".

I believe it is so.

Don't be a Debbie Downer. You are not even female.

Craig

Are you sure I'm not female?

I was, indeed, once male (and according to Donald Trump always will be), but at present, who is to say . . . and, quite frankly if D. Trump is the model for malehood I'll be down in the kitchen with that Chinese slicing thing faster than you can say 'Make America Crap Again'.

Gender concerns aside, I feel like this has changed.

For instance, the behaviors tab of the property inspector offers to create a new script stack for the behavior, and doesn't seem to allow the selection of a button object - just stacks. It does work... if I put behaviors in the stack script of the script-only stack, the object with that stack assigned as its behavior source reacts as expected.

I feel like this has something to do with source control compatibility perhaps, but it seems to indicate a preferred pattern of app design.

It is different than I remember it, but granted it has been a while.

I tend to put behavior scripts in buttons. When I use LC it's usually for proprietary works where the script encryption is s useful feature.

If the IDE UI no longer supports this you might report it. Could just be a bug.

Thanks guys.

The issue was that the behavior wasn't yet in the message path so only stack shows up in the dialog.

Still immediately placing buttons into a "script only" stack that contain buttons seems a misnomer.

It's just me being away from LC for some years. Case closed.

Regarding the subthread here about new versions (10.0.2 RC 3) breaking old stacks, the latest release fixed a regression by reverting to an older version of that component in question.

Craig

Troy wrote: ↑

Wed May 07, 2025 4:32 pm

Are behaviors in external stacks still the recommended approach for scripting? The new system seems to imply a single stack script per object - am I inferring that correctly?

All of this seems to indicate a (possibly new?) general structural approach to LC app design that I'm not clear on, and isn't clearly indicated in the stuff I've seen written (legacy help files). Should I have a whole bunch of external script-only stacks to manage my code now? Is there a recommended pattern?

I'm pretty sure you are mistaken - also not sure where did you get the 'external' stacks recommendation from?
Even LC, with their amazing Data Grid object, use a substack, although the IDE does use a large number of script only stacks as well.

Having just checked in LC 10 to confirm, I can't see any new changes:
Create a stack, add 2 buttons (1 called "behaviour" and 1 called "test") and add a substack; save (so the substack is available).
In in the property inspector of the 'test' button go to the "Advanced" tab and in the "behaviour" bullseye you will see both buttons, and a "stack" menu, who's menu items will include a number of LC stacks as well as the substack and mainstack.

As to recommended approaches, I personally would only use external stacks where I want a reusable behaviour I can use in multiple projects; otherwise I'll use substacks or buttons. If in a large team however it makes sense to use external behaviour stacks so different groups can independently work on different behaviours without affecting the mainstack.

While script-only stacks are nice because they can be edited directly in editors like BBEddit or VSCode and more importantly are perfectly suited for version control systems like git/GitHub/etc, these are unsafe to distribute with an app because they can be edited/modified/deleted/copied by end-users and it's pretty rare I'd be happy with that. But for large collaborative projects the version control makes this probably mandatory.

Substacks/stacks also have the benefit of being able to contain buttons for further behaviours; as you can chain behaviours, if you have need of that you can encapsulate everything within the the single stack/substack object. Buttons are nice for this because you can add to a group as a hidden button

The downside with buttons in a group is that if the group is copy/pasted, the id of each group member is assigned as new number which will break the link to the behaviour, so you need to have some code in the group's script (eg in resizeControl) to set the behaviour to the id of the button by long name.