Using external script only stack as behaviour

[stam]

Any suggestion?
I would like to use a folder in order to keep things a little more ordinate, since I will have tens of script only stack.

You may find my solution skScriptLoader helpful - available on GitHub.
It was designed specifically for use of many SO stacks with an external code editor.
In your case, you could create behaviour stubstacks that would be assigned a script-only stack as a behaviour so you can edit freely externally.
I've put a lot of detail into the readme file but there is also in-app documentation. I created this specifically for my needs, but you may find it helpful hopefully.

Edit: see more about this here: https://forums.livecode.com/viewtopic.php?f=9&t=37336

HTH
Stam

[Klaus]

Hi Trevix,

it does not makes sense to use a SWITCH for the SAME values!? -> specialfolderpath("resources")

This is a bit shorter, but still does not what you want:

Code: Select all

On Preopenstack
   
   ## Avoid avoidable IF THEN END IFs:
   if "ButtonNext Behavior" is in the openstacks then
      pass preopenstack
   end if
   
   put specialFolderPath("resources") & "/Beh_scripts/" into tPathToBeh
   put files(tPathToBeh) into tList
   ## answer tList
   repeat for each line tStack in tList
      if "Behavior" is in tStack then
         
         ## This does not actually load them into memory, at least not the way you exspect.
         ## What do you want to do?
         get the short name of stack (tPathToBeh & tStack)
      end if
   end repeat
end Preopenstack

You should use that loop to assign the behaviours to your controls!


Best

Klaus

[trevix]

Hi.
The switch was a left over of my testing, when I checked, just in case, various folders for Android and iOS and desktop. It doesn't matter.

I assign the behaviour to buttons on development, using the property inspector (Behavior/Create behaviour script only stack/Create stack with empty script).
It does not make sense for me to re-do the assignment on standalone launch, since I will have hundred of controls with behaviour...
With behaviour buttons, you link them and that's it.

Somehow, when opening the main stack, even on development, the property inspector (stack "ButtonNext Behavior") loses its reference, even if the behaviour stacks are loaded in memory.

To recap (desktop):
- the "ButtonNext Behavior.livecodescript" file and the "PrevPrev Behavior.livecodescript" file are both inside a folder "Beh_scripts", at the same level of the main stack.
- my buttons, on the main stack, in their property inspector have the correct name of the behaviour stack.
- I open the 2 behaviour stacks on PreopenStack of the main stack (just getting the name doesn't work either)
- at this point the 2 behaviour stacks are listend in the Openstacks (so should be in memory)
- the behaviours don't work. Will work only if restablishing the behaviour on the property inspector, but will not work again on the next launch.
- the behaviours work only if the behaviour stacks files are out of a folder, at the same level as the main stack (same on mobile).

Since behaviour using behaviour buttons works fine, always, why it does not work using script stacks? Do I need to set the stack ID on the property inspector?
What am I missing?
See the attached example stack (it was created to study the "open substack in window", which, by the way, works fine for closing the substacks behind, when going to a new one...).

[bwmilby]

The problem is that at “preOpenStack” it is too late. Behaviors are resolved when the stack is loaded from disk before any messages are processed. References to objects within the stack require no special consideration. SOS behaviors do. In general, the engine needs to be able to locate the behavior when the object is loaded.

Did you try enumerating every behavior in the stack files?

[trevix]

Thanks for the clear explanation. Now, I understand.
But his doesn't explain why if the SOS are at the same level of the main stack, the behaviours work.
Are you saying that the engine looks around for SOS and load them only if they have the same path as the main stack?

Did you try enumerating every behavior in the stack files?

What do you mean?

[trevix]

Ah, you mean the "StackFiles"?
And if yes, how to address the folder containing the SOS?
DefaultFolder?
Like this?

Code: Select all

On PreopenStack --main stack
   set the defaultFolder to tPathToSOSfolder
   --probably a loop on the files list
   set the stackFiles of this stack to "PrevPrev Behavior.livecodescript" & cr & "PrevPrev Behavior,PrevPrev Behavior.livecodescript"
end PreopenStack

Cumbersome...

[jacque]

You can list the stackfiles in the stack property inspector and be done with it. LC will look there for the correct path.

But I do wonder why you don't just use buttons for the behaviors. They are always found, and easy to link. You can put all of them in a substack or on a dedicated card. There is no particular advantage to SOS unless you are contributing to git, which is why they were invented. I find behavior buttons to be far more convenient and they require no additional scripting.

If I only have a few, I sometimes just put them in a hidden group on the first card. That way they don't interfere with navigation like a dedicated card would.

[trevix]

Actually now I am using buttons, for behaviour. In my standalone I have almost 30 of them in a dedicated card, as you suggested.
It bothered me that in the property inspector are listed by ID, while you add the behaviour by the short name (with is how they look in the dedicated card). Sometime it was a mess, since it was hard to find out wich one you assigned and there was no way to categorise the list...
I was hoping to find a better method but, thanks to your suggestion, I think I will continue this way, may be organizing my self a little better.
Thanks

[bwmilby]

The actual problem with your demo stack is that it had the behaviors listed twice in the StackFiles. Once at the root level and once in the folder. This is what prevented them from being found and mapped properly as behaviors. If you delete the entries that are not in a folder, save, quit and relaunch LiveCode, then they work as expected.

[jacque]

It bothered me that in the property inspector are listed by ID, while you add the behaviour by the short name (with is how they look in the dedicated card). Sometime it was a mess, since it was hard to find out wich one you assigned and there was no way to categorise the list...

By popular demand, LC added a couple of ways to determine the behavior of an object. You can right-click and choose "Edit behavior script" from the contextual menu. Or you can look in the property inspector's Advanced pane where there is an Edit Behavior button and a reference to the behavior script, though you're right the IDs aren't very informative.

[stam]

Or you can use the Project Browser and click the ovals behind each object to open its behaviour.

[trevix]

@jacque
I would be nice to have a check mark next to the assigned behaviour button (in the list of the property inspector).
In this way you know the ID AND the name.

[stam]

@jacque
I would be nice to have a check mark next to the assigned behaviour button (in the list of the property inspector).
In this way you know the ID AND the name.

Again, the Project Browser lists the name and shows the ID in a tooltip; and any attached behaviour (even for chained behaviours) show up as ovals next to the square on the right. Option-click to show a contextual menu to access the property inspector for that object. Clicking on the square opens the object's script; clicking on the ovals opens the behaviour script in question.

It's actually a pretty useful tool - but it's hidden in the Tools menu and can be a bit buggy.
Hopefully the new IDE will put that in a position of prominence and fix the bugs...

[trevix]

This is what I am talking about.

[Klaus]

This is what I am talking about.
Behaviours.png

Don't you have a smaller image?

Well, you did not give your behavior buttons meaningful names, so I'm not sure what you are complaing about?