Something to remember when scripting substacks

[RCozens]

Morning (here) all,

I first encountered this issue last year when I added a palette substack to Serendipity Editors. Apparently that lesson didn't sink in, because I made the same omission this week.

If a substack does not handle or block preOpenStack, openStack, and/or closeStack messages in its stack script, the messages are passed to the main stack.

So, for example, if a substack has no preOpenStack handler and one doesn't want the main stack's preOpenStack to run when the substack is opened, the substack must block the message:

Code: Select all

on preOpenStack
  -- block preOpen messages
end preOpenStack

Cheers!

[Klaus]

I always use this "trick":
I put my "pre-/openstack" handlers into the script of the first card of the mainstack!
Eliminates the need of "dummy" handlers in the substack(s).

[stam]

Thanks for the heads up @RCozens, I was completely unaware and yes this could be a nasty gotcha as bugs will be difficult to locate…

@klaus: thanks for the workaround… but that doesn’t sit entirely right with me in the sense that I want stack wide stuff to be in the stack script and card-wide stuff to be in the card script, and I’d prefer to keep this separation for my own sanity!

I am not sure about the logic of a substack triggering the mainstack handlers if not implemented in the substack. That seems like you’re just asking for trouble if you ask me…

Is it worth a bug report/feature request to either stop this from being the default (if needed you could always pass the handler in question) or at the very least on creation of substacks to have all the relevant handlers added to the substack’s script by default, with a comment to devs as to why?

S.

[Klaus]

Hi Stam,

@klaus: thanks for the workaround… but that doesn’t sit entirely right with me in the sense that I want stack wide stuff to be in the stack script and card-wide stuff to be in the card script, and I’d prefer to keep this separation for my own sanity!

I did not mean that would be suitible for everyone!

I am not sure about the logic of a substack triggering the mainstack handlers if not implemented in the substack. That seems like you’re just asking for trouble if you ask me…

Is it worth a bug report/feature request to either stop this from being the default (if needed you could always pass the handler in question) or at the very least on creation of substacks to have all the relevant handlers added to the substack’s script by default, with a comment to devs as to why?

No, this is definitively a feature, changing this would break the complete meaning of the message hierarchie!


Best

Klaus

[stam]

I get what you’re saying - but my point is that why should an openStack message generated from the substack trigger the openstack message of the mainstack?
Makes little sense…

In my mind this should be the exception to the message path. It is only the 4 stack messages this concerns - pre/openstack and the close stack messages.

This should not be an issue for the message path otherwise, as the user (or the dev) will never send an openstack message from the substack and expect the mainstack handler to deal with it.

Might not be feasible.

But a fallback position is that when you generate a substack, these messages are automatically added to the substack script, with a comment explaining.

[Klaus]

This should not be an issue for the message path otherwise, as the user (or the dev) will never send an openstack message from the substack and expect the mainstack handler to deal with it.

I could agree if you replace "the user (or the dev)" with "I" (eye)!
I have used this feature many times in the last 22 years of using LC and its ancestors.

[jacque]

I put common handlers in the first card too most of the time but there are frequent occasions where I want the handlers to be executed in all stacks. Often these are closeStack handlers that need to do the same cleanup for all stacks, or openStack handlers that adjust properties of controls common to all substacks. For example, a closeCard in the mainstack allows me to delete all mobile controls without putting the commands in every card. I rely heavily on the message path to consolidate scripts.

This behavior has been standard since the beginning so it's unlikely to change. For me, the most common mistake is forgetting to pass the handler if I do need a custom one that applies extra changes not included in the mainstack handler.

[stam]

I could agree if you replace "the user (or the dev)" with "I" (eye)!
I have used this feature many times in the last 22 years of using LC and its ancestors.

And therein lies the issue - people who have been using this approach for > 20 years are fine with it because they've learned to work around the issue.

Do i really want a popup calendar substack i created to trigger the mainstacks' preOpenStack handler? i can't think of single reason for this - although i understand this may be something a dev (i.e. YOU ) may wish to do.

Because it then becomes an unanticipated source of error for those how are new to the platform, it's just inviting trouble especially for new users.

The simplest fix would be to pre-populate the substack script (on creation) with the handlers to trap the events to protect the unwary (eg ME). A comment can be added, say, to explicating tell the devs to pass the handlers if you want this be handled in the mainstack.

I imagine this would be trivial to implement.
This way the current message path would be left intact, the dev could simply delete or pass the handler if the mainstack is to act on it. But it would change the passing of these handlers a conscious act rather than the default (which is pretty much guaranteed to be unknown to new users and many intermediate users).

Anyway, that's how i see it... (from the point of view of someone who hasn't been using LiveCode for 22 years )

[Klaus]

OK, you are probably right: force of habit...

[SparkOut]

Well, I started out thinking like stam, that it was not a natural way to think of substacks causing the mainstack open and close events to fire.
I didn't understand or feel comfortable with putting stack event handlers in a card script, it struck me as a kludgy workaround. I spent many hours making much, much kludgier workarounds, with scripts checking the name of the stack invoking the event and acting accordingly.
I sort of graduated to making empty handlers to trap events so as not to mess with the mainstack. But then when I really got to grok the message path I just realised the elegance and understood a whole lot more about the paradigm. Messages are meant to pass through card 1 before the stack. During original development it could have been made to work differently and we'd have a product that looks quite different now. But it was developed around the message path, not bending the message path to fit.
It's not a kludge at all, and it's more like a tool that is meant to be leveraged in that way. It actually isn't for getting stones out of horses' hooves, it's to separate the strands in a rope for splicing.
That's just how I think. Doubtless raising awareness of this for newer users would be advantageous.

[FourthWorld]

...But then when I really got to grok the message path I just realised the elegance and understood a whole lot more about the paradigm. Messages are meant to pass through card 1 before the stack. During original development it could have been made to work differently and we'd have a product that looks quite different now. But it was developed around the message path, not bending the message path to fit.
It's not a kludge at all, and it's more like a tool that is meant to be leveraged in that way.

Bingo.

There was no point in making another xTalk that works exactly like HyperCard.

In June 1989, Bill Appleton's SuperCard extended the message path with an abstract container around stacks (which SC calls "windows") which it calls a "project". SC also had menus as objects, its own resource management, and other extensions to the HC object model, and the extra project container made a great way to keep all the parts in one file.

When MetaCard premiered in May 1992 (Happy 30th birthday!), Dr Raney took a different approach, one that allows the multi-stack container SC provided, but where the container was a stack itself. This allowed for a more HyperCard-like experience when making HyperCard-like single-stack works, while embracing SC's ability to deliver rich multi-window apps in a single file.

The key to using anything beyond HyperCard is to remember that the outer container is the last stop for messages within the file's objects.

And the key to enjoying smooth development with MetaCard/LiveCode specifically is to consider the order of presentation to the user.

What sometimes happens with MC/LC is folks will begin sketching out the main window of something they have an idea for, and if they later decide to make it an app they'll add the other windows they need as substacks (About, Preferences, etc).

But the first thing the user sees is usually a splash window. Put preOpenStack init stuff in that card script and you have init happening where you want it, in the first object that gets the message, without interfering with anything else.

If your splash doubles as About, it's simple enough to add one flag to your init so it only happens once at startup - certainly simpler than making stub handlers in every substack for every message you want to block.

Several years ago I took this awareness of presentation order even further, architecting so that the mainstack is an error report that init failed. This gives me the freedom to do any setup needed for any other window, but if for some reason the preOpenStack init fails at least the user has proper notification. Most never see it, but it's been a comforting insurance policy against bad installs.

The bonus for an ultralight mainstack is how it allows me the option to externalize EVERYTHING the users sees from the standalone, all the way down to even the splash stack. In recent years most of what I make is client-server, and in addition to downloading the data used the app also downloads the interface as well. This lets me deploy one standalone, yet constantly update what they m the user interacts with as easily as updating a web page.

There are so many ways to use the innovative MC/LC object model powerfully.

If writing stub handlers in every substack is enjoyable, don't let me stop you.

But there's no need for that if you put init stuff where init happens first: in the first object that gets init messages, the first card of the mainstack.

[jacque]

In the old scripting conferences from eons ago, one of the first things we present to the new user is the message path. You can't get very far without understanding how it works. All messages use it, and excluding a subset or blocking a subset is bound to cause confusion even for new users. They are likely to think this is a required way to script, or at least a strongly suggested way.

[stam]

Several years ago I took this awareness of presentation order even further, architecting so that the mainstack is an error report that init failed. This gives me the freedom to do any setup needed for any other window, but if for some reason the preOpenStack init fails at least the user has proper notification. Most never see it, but it's been a comforting insurance policy against bad installs.

The bonus for an ultralight mainstack is how it allows me the option to externalize EVERYTHING the users sees from the standalone, all the way down to even the splash stack. In recent years most of what I make is client-server, and in addition to downloading the data used the app also downloads the interface as well. This lets me deploy one standalone, yet constantly update what they m the user interacts with as easily as updating a web page.

That's fascinating!
I think you did mention this in passing during the conference but was only able to watch this in retrospect so couldn't ask for more info, but you give more clues here...

So basically your mainstack is a stack that performs some init and only shows an interface if there's an init error, otherwise it will grab interface and other stacks from an online server, download as needed and then launch the user-accessible part of the app? And presumably this handles updates for individual stacks as well?

If this is correct that's a really nice approach, I will definitely try to do something similar...
If i've misunderstood, would be grateful for more info!

Stam

[FourthWorld]

So basically your mainstack is a stack that performs some init and only shows an interface if there's an init error, otherwise it will grab interface and other stacks from an online server, download as needed and then launch the user-accessible part of the app? And presumably this handles updates for individual stacks as well?

Yep. And unless I need something separate, I keep all the real meat of the app in one stack file. I have a plugin that gZips it, posts it to my server, and updates a version file there. The client app checks the version file, IU if there's a new version downloads it, unzips it, and put it where it needs to be to complete init.

I've had a couple times when I'm in meetings and the team will mention a bug, and before the meeting is done I can tell them, "That bug you mentioned at the start of the meeting? It's fixed and delivered - just open the app to see the changes."

Lots of folks I know do things like this. I have one app we only replaced the executable for maybe twice in eight years, even though we delivered updates almost every month.

For a living example see GoLiveNet in the Plugins menu - the UI it displays is a stack file that lives on one of my servers (and the data it displays comes from half a dozen different servers, but that's another story).

[andresdt]

Hi everyone, as @Klaus already said it's part of the flow. So it's not a mistake.

If you don't want the substacks to execute the code you have in the preOpenStack of the mainstack. In the preOpenStack check that it is the mainstack otherwise pass the message and that's it.

Code: Select all

on preOpenStack
   if me is not the target then pass preOpenStack
   ...
end preOpenStack

or

Code: Select all

on preOpenStack
   if the name of this stack is not  the name of me then pass preOpenStack
   ...
end preOpenStack

hope this helps