Splash snafu

[Richard Gaskin]

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,
e.g.:

   on openStack
   end openStack

   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:

   on openStack
     if the short name of this stack is "MyMainSack" then
         -- do stuff specific to the mainstack
     else
         -- do stuff for all other stacks
     end if
   end openStack

   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
messages).



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.  :)

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc