SparkOut wrote: ↑Sat May 14, 2022 9:16 am
...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.