ambassador at fourthworld.com
Tue Dec 23 16:18:58 CST 2003
PROBLEM: Putting a handler in a mainstack makes it triggerable by messages
passed or not handled in substacks. While a useful feature, if
unanticipated it can have undesired consequences.
ONE SOLUTION: Put a stub handler in every substack to trap those messages,
Downside: it can be a lot of typing, and if you later need to have
a common behavior for such messages you need to go back and modify
every stack script.
SIMPLER SOLUTION: Add an evaluation to your mainstack's handlers for those
that apply only to the mainstack:
if the short name of this stack is "MyMainSack" then
-- do stuff specific to the mainstack
-- do stuff for all other stacks
Downside: It's a little extra typing, and if you later change
the name of the mainStack you need to modify the code to match.
EVEN SIMPLER SOLUTION: Put mainstack-specific handlers in the card script
of your mainstack, leaving the stack script available as a common library.
If your mainstack contains muliple cards you could use the script of a
shared group (be sure to turn on its backgroundBehavior so it'll catch
A general note about stack structure
The following is merely a reflection of my own practices, and not
necessarily a recommendation. I've been burned using a wide variety of
other structures over the years and now use this one for everything I build
fresh, but it's as much a matter of preference as anything else so use or
ignore at will:
Once upon a time I had the mainstack of my apps be the About box. All was
right with the world until my app encountered a low-memory condition (more
likely with Mac OS 9 than others, as others have really good VM). In such a
state there may not be enough memory for the engine to throw the exception
as it would for other errors, or for me to open a dialog explaining the
problem to the user. The result is a mysteriously frozen splash screen, and
a confused and dismayed user who now has the impression I turn out sloppy
code with inadequate error-checking.
Today my mainStacks are a dialog notifying the user of a memory error. I do
initialization from a preOpenStack handler in its card script, with the last
line being to hide the window. When all goes well (99.99% of the time) the
stack is never seen; if it is seen it is most likely because of an error
related to initialzation, which is either caused by a bad install or low
memory; both possibilities are described in that dialog, with a brief
recommendation to increase memory allocation (if on Mac 9) or re-insall,
with my support number displayed there if they need further assistance.
- By keeping initialization in the card script I have the stack script
available as a common library.
- Having the mainstack be something that is ideally never seen gives me the
option of externalizing every visible element, including the About box, to
separate stack files if I need to do live updates.
- In the unlilkely event that the mainstack is seen, I've presented
meaningful info for the user under circumstances where it may not be
possible to do so by any other means.
I recognize that this is an unintuitive approach and may seem an overzealous
use of defensive programming principles. But it lets me sleep just a little
better at night. :)
Fourth World Media Corporation
Ambassador at FourthWorld.com http://www.FourthWorld.com
Tel: 323-225-3717 AIM: FourthWorldInc
More information about the use-livecode