LiveCode Forums.

So I was working on a project which had a main stack and a number of sub stacks, all was working well and then.. bam! my main stack re-initialized all my base settings again..WHAT!
After cursing LiveCode for a while and trying to glue what hair I still have left back into place, it was time to find out what I had done wrong.
I had forgotten about the message path in relation to Main and sub stacks.

Heres wahat happened.

In my Main stack I had a preOpenStack handler that initialized values and control positions.
In one of my sub stacks I had forgotten to trap the preOpenStack message so that the message does not get passed up the message path to the Main stack.

So I was about to code this into my sub stack and thought there must be a better way to do this, do I really have to trap the messge in each and every substack, No I did Not!

The answer is obvious, simple and elegant which is why I proberbly missed it, being entrenched in my coding habits.

All I needed to do was to check in the preOpenStack handler of the Main stack that the preOpenStack handler was initialized from the Main stack. so the code changed to:
Breakdown, the check is
If the target function which determines which object originally received the message. In this case the main stack.
Is the same as Me that referes to the object that contains the current script, again the Main stack
Then run the initialize code.

So with this check in place I can now forget about adding trapping code to the sub stacks and have a much leaner and code safe app.

Moral of the story : The Message Path is your friend, unless of course you forget about it

AndyP wrote: ↑

Fri Mar 05, 2021 1:14 pm

All I needed to do was to check in the preOpenStack handler of the Main stack that the perOpenStack handler was initialized from the Main stack

While I know I've been stung in the past the same way, I'm curious about something here Andy, why not just stick the openStack and preOpenStack code into the first card of the stacks script?

Wouldn't that take it out of the regular MessagePath far enough to only trigger on opening the main stack? (i.e. when you open another stack, it isn't going to follow any path to the first card of the main stack).

bogs wrote: ↑

Fri Mar 05, 2021 1:23 pm

AndyP wrote: ↑

Fri Mar 05, 2021 1:14 pm

All I needed to do was to check in the preOpenStack handler of the Main stack that the perOpenStack handler was initialized from the Main stack

While I know I've been stung in the past the same way, I'm curious about something here Andy, why not just stick the openStack and preOpenStack code into the first card of the stacks script?

Wouldn't that take it out of the regular MessagePath far enough to only trigger on opening the main stack? (i.e. when you open another stack, it isn't going to follow any path to the first card of the main stack).

True, but as I said I'm entrenched in my coding habits and I feel it's just right to put a preOpenStack or openStack handler in a stack and not a card.

I'll agree with that sentiment, just be warned that "this stack" (at least in the IDE versions I use) doesn't always produce a reliable result (in other words, I always use at minimum stack "nameOfStack").
The additional keystrokes are worth it to me to type it that way, but again, that may just be a result of using antiquated versions of the IDE.

Andy.

I am not only entrenched, I am mired.

But I like the concept of using the first card as opposed to the stack itself. I find it comforting to know that the card script is isolated from the rest of LC, and, after, all, since the first card MUST open, assuming one does not navigate to another explicitly, its script is a secure place to do any setup processes required, protected from the cold cruel world outside.

Craig

dunbarx wrote: ↑

Fri Mar 05, 2021 3:43 pm

Andy.

I am not only entrenched, I am mired.

But I like the concept of using the first card as opposed to the stack itself.

It's certainly less work, and less prone to failure from forgetting to replicate stub handlers every time you make a substack.

It's like using abbreviations or learning menu shortcuts, and much of life in general: it may not reflect our earliest habits, but it's a useful habit to adopt through practice.

dunbarx wrote: ↑

Fri Mar 05, 2021 3:43 pm

I am not only entrenched, I am mired.

I guess if he is "entrenched" and you are "mired", then I am locked in "reinforced unobtainium"

dunbarx wrote: ↑

Fri Mar 05, 2021 3:43 pm

the first card MUST open, assuming one does not navigate to another explicitly

but AFAIK you can't explicitly navigate to another card until the stack is open, which means that the preOpenstack and openStack messages will be sent to the first card, so that is safe. And if you navigate to the first card after the stack is open then the preOpenstack and openStack messages are not generated so that is also safe.
It took me a while to grok the idea of a "stack" message being handled on the "card" script, and I was slightly reluctant (as I perceived it) to "bend" the message path, thinking it somehow lazy, and went to lengths to explicitly trap messages in substacks, and check names of targets matching stacks. Then I realised that the message path is intended to work that way. It really is a valuable feature, secure and robust.

I just tested this and you can directly navigate to a specific card on an unopened stack. So as long as you know that you will never directly navigate to a specific card, you are safe putting the code in the first card.

Stk A - list Stk B in the stack files, button script go card 2 of stack "StkB"
Stk B - preOpenStack script on cd 1 put "preOpenStack" && the long name of me

Quit LC. Open Stk A. Click the button and Stk B opens to card 2 but you get no message.
Quit LC. Open Stk B and you get the message.

Well, you never stop learning! Thank you Brian.

bwmilby wrote: ↑

Sun Mar 07, 2021 2:41 am

I just tested this and you can directly navigate to a specific card on an unopened stack. So as long as you know that you will never directly navigate to a specific card, you are safe putting the code in the first card.

For init code as we're discussing here it'll be fine.

The first card of the mainstack of the stack file used to begin a session is the entry point for all things.

It is only later, after init is done, that some other script may intervene to go to an explicit card in that mainstack. And by that time our init has already been completed long ago, so that the init code isn't called a second time won't adversely affect anything.

If you have a project with dozens of stacks that are not all loaded at once, you can get into a state where the preOpenStack is not called if it is included in the card script. The test that I uploaded shows how this can happen. I’m not talking about the launch stack, but any other stack in the project.

Attached is an updated demo that shows the difference with the preOpenStack being in the card 1 script (StkB) and the stack script (StkC).

Oh yes indeed, once the app is up and running LiveCode's flexibility will let you do all sorts of things.

But the first card of the mainstack is where the runtime lifecycle begins, and as such it's a very good place for init routines.