Page 2 of 2

Re: Using external script only stack as behaviour

Posted: Tue Oct 15, 2019 10:29 pm
by bogs
FourthWorld wrote:
Tue Oct 15, 2019 10:12 pm
Simply opening any stack will not cause it be to used as a library.
I'd agree with that, however, I don't think that is what was happening here either. What I think I finally figured out after reading this again --
kaveh1000 wrote:
Tue Oct 15, 2019 12:52 pm
Attaching minimal example stacks. I have set Main stack to have behaviour of script_stack.livecodescript. In the stack script of the latter I have:

Code: Select all

on openstack
   answer "hi"
end openstack
When opening Main Stack why does it not answer "hi"?
-- is that once you make the script stack a sub stack of the main stack, it is not triggering because of the behavior (the desired outcome), but because when the main stack opens, it also opens this as a sub stack, and the substack on opening triggers the openStack handler.

Of course, I had to re-read that one a few times, so I am guessing I am just not up to the challenge today haha.

Re: Using external script only stack as behaviour

Posted: Tue Oct 15, 2019 11:47 pm
by jacque
However, what I did before posting the last was -
take kaveh's un-altered example up there
make it a substack of the main stack in his example (was intirgued by your post)
save it all that way
PROFIT! Erm, I mean, then I reopened it and it seemed to work.
If you didn't didn't remove all stacks from memory (or restart LC) then the stacks were probably still in RAM when you did the test.

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 12:10 am
by FourthWorld
[-hh] wrote:
Tue Oct 15, 2019 10:27 pm
Just as an additional remark.
If I remember right there was last year a post by Mark Waddingham who said it was never intended to use "set the behaviour" to anything else than to a button. And that this may be restricted to buttons in future versions.
That was true, but before the addition of script-only stacks (SoS).

SoS were added for many reasons, but not the least of which was the LC team's own need to use version control systems.

SoS are here to stay, and are recommended for use as libraries and behaviors, just as they're used in the IDE.

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 2:35 am
by bwmilby
Need to add the behavior to the Stack Files of the main stack. Behaviors do not need to be placed in front/back or have "start using" called on them. They just need to be in memory when the object that references them is opened. When the main stack file is loaded into memory, some work is done to place referenced stacks into memory.
StackFiles.jpg
Missing piece...
And yes, after making the change in the image, I completely exited the IDE and reloaded it. When I opened the stack, I did get the "hi" message.

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 11:33 am
by bogs
jacque wrote:
Tue Oct 15, 2019 11:47 pm
However, what I did before posting the last was -
take kaveh's un-altered example up there
make it a substack of the main stack in his example (was intirgued by your post)
save it all that way
PROFIT! Erm, I mean, then I reopened it and it seemed to work.
If you didn't didn't remove all stacks from memory (or restart LC) then the stacks were probably still in RAM when you did the test.
I forgot to list that step, but yes, even as bwmilby said, after saving it that way I closed the entire IDE out just to make sure it was flushed. I suppose I should have also set the destroy stack on both to true, but I forgot that step :oops:
bwmilby wrote:
Wed Oct 16, 2019 2:35 am
And yes, after making the change in the image, I completely exited the IDE and reloaded it. When I opened the stack, I did get the "hi" message.
Yes, but the question I now have is, did the "hi" message pop up because it is in the openStack handler of the script stack, or because of the behavior setting? In my previous post, I am assuming it is because of the former, not the latter :?

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 2:49 pm
by dunbarx
If I remember right there was last year a post by Mark Waddingham who said it was never intended to use "set the behaviour" to anything else than to a button. And that this may be restricted to buttons in future versions.
I always thought that having a button as the only repository of a behavior was bad behavior. I mean, a button? A small control that has to be cradled on a card in a stack? The beauty of behaviors is that they can catch the messages of a vast array of gadgetry within one's project. To have an object much smaller than that scope, an isolated control buried somewhere, seems untoward. And LC barks when it encounters "large to small" chunk stuff.

A stack is the proper place for behavior scripts.

Craig

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 3:31 pm
by bwmilby
bogs wrote:
Wed Oct 16, 2019 11:33 am
Yes, but the question I now have is, did the "hi" message pop up because it is in the openStack handler of the script stack, or because of the behavior setting? In my previous post, I am assuming it is because of the former, not the latter :?
I added “put the long id of me after msg” to the behavior to be sure and the result was the stack opening and not the behavior being referenced. I’m pretty sure that the reference to a behavior stack in this way does not generate the ‘openStack’ message.

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 3:43 pm
by bwmilby
dunbarx wrote:
Wed Oct 16, 2019 2:49 pm
I always thought that having a button as the only repository of a behavior was bad behavior. I mean, a button? A small control that has to be cradled on a card in a stack? The beauty of behaviors is that they can catch the messages of a vast array of gadgetry within one's project. To have an object much smaller than that scope, an isolated control buried somewhere, seems untoward. And LC barks when it encounters "large to small" chunk stuff.

A stack is the proper place for behavior scripts.

Craig
I disagree. Why litter up the namespace with loads of stacks when all of the scripts can be collected on a single card as a bunch of buttons? The location of the button doesn’t really matter, the message path is based on the object that has the behavior. If you are using script only stacks for version control, that does make sense but not for the scope reason.

My opinion here is also based on the in memory structure of the data. The linked list of main stacks will have an entry for every stack. This list is traversed when looking up objects. Fewer entries here would seem to make finding things in other stacks faster since the stack is the first object that needs to be located. I have yet to devise a way test this out to see impact, but it is a theory that I have.

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 4:23 pm
by bogs
bwmilby wrote:
Wed Oct 16, 2019 3:31 pm
I added “put the long id of me after msg” to the behavior to be sure and the result was the stack opening and not the behavior being referenced. I’m pretty sure that the reference to a behavior stack in this way does not generate the ‘openStack’ message.
Good to know!
bwmilby wrote:
Wed Oct 16, 2019 3:43 pm
I have yet to devise a way test this out to see impact, but it is a theory that I have.
Heh, if you come up with a way to test it, speaking only for myself, I'd love to see it :D

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 4:46 pm
by jacque
Gotta agree with Brian here. If you aren't using a version control system, adding stacks to the build is unnecessary. And if they are separate stacks, on any non-Mac OS it will produce a litter of extra files that can be lost or separated from the parent stack.

Separate stacks also interfere with debugging because, at least at present, the script editor can't always find them when tracing through code.

Re: Using external script only stack as behaviour

Posted: Wed Oct 16, 2019 9:20 pm
by dunbarx
I see what you are all talking about. But one does not have to add additional stacks. I have used a single stack as a repository of one or more behaviors.

You might say, "why not just place handlers normally in the stack script, and use the hierarchy"? Well, I could, and of course do.

I guess it just always rubbed me a little the wrong way that a lowly button was so empowered. Your points are that the smallness of those controls is actually a good thing. Hmmm. OK.

Anyway, it is all good.

Craig

Re: Using external script only stack as behaviour

Posted: Thu Oct 17, 2019 10:20 pm
by kaveh1000
Hi all. Thank you for your comments. Sorry was offline for couple of days.

The main solution to my problem was first pointed out by Jacque, namely to use stackfiles. I did not know what this was. Brian then helpfully added the screenshot. So this works with no scripts needed.

I am happy now that I have a simple script only stack (with some 6000 lines) that I can use version control on and work with a colleague to modify. So here is my next problem. I hope ok to continue this thread...

What is the most painless way of using version control? Ideally I want to do my editing within LiveCode, so that I have stepping, live debugging, etc. Can i do this? Do I need to check out, check in every time I want to edit? There are two of us working on the code. I do understand I would need to be in a version control program to see the changes.

What about using Levure, or is that overkill for just one script?

Any advice welcome.

Re: Using external script only stack as behaviour

Posted: Fri Oct 18, 2019 3:46 am
by bwmilby
As long as all changes are being made to the text files, Git can handle merging things together. You will probably want to work on separate branches though. Any changes to the binary will need to be carefully controlled and usually done by one person at a time since there is no way for Git to handle that natively.

Take a look at the LiveCode source and the pull requests to get an idea of how things flow. Much smaller scale, you can look at some of the other LiveCode projects on GitHub too (that is where I put my stuff that is shared, but I’m the only one doing commits).

When I’m working on a project where 2 people are working the same branch, I make sure that the other person is not working the same stuff as me and that all work is pushed. I then pull to be sure I have the latest version of everything. When done with my changes, I will commit and then push and let the other dev know that there are some changes to pull. If you both change a file, then you will need to reconcile the differences to get everything back in sync.

Re: Using external script only stack as behaviour

Posted: Wed Jul 29, 2020 8:15 pm
by alextweedly
You really don't want to "start using stack ..." for a behaviour stack.
That starts using it as a library stack, putting it in the back of the message path - and therefore those handlers will be called (out of context) if the message is not handled elsewhere.

It is enough to ensure the stack is in memory - which you can do by referencing any property of it, e.g.
get the name of stack "SomeStack"

(See Richard Gaskin's post at the end of the thread at
http://runtime-revolution.278305.n4.nab ... 02715.html

I currently do what he mentions - walk through the stack and update al controls with a bit of code like:
get the name of stack (specialfolderpath("resources") & "/blahblah.livecodescript")
local tmp
repeat with x = 1 to the number of controls in this card
put the behavior of control x of this card into tmp
if tmp is not empty then
set the behavior of control x of this card to the long id of tmp
end if
end repeat