Re: Newbie - MainStack Question

[Rob Cozens]

Has this ever caused a maintenance problem for you?
Hi Again, Brian.

First, let me say that when I was first introduced to x-Talks via 
HyperCard after fifteen years of "traditional" programming, one of 
the greatest difficulties I had was becoming familiar enough with the 
message hierarchy to understand how the logic I scripted in a mouseUp 
handler going to another card or stack might be affected by the 
mouseLeave, close, preOpen, open, & mouseEnter handlers in the 
affected controls...and to remember to factor in the consequences of 
other handlers that they might trigger.

What I'm saying is I am thinking about your issue in the broader 
context of message hierarchy rather than assigning a fixed location 
for each handler.  In that context, & within the framework of your 
mainStack/subStack example--it applies to library stacks in use as 
well--, placing preOpenStack & openStack handlers in a location other 
than the stack script simply works correctly, while placing the 
handler(s) in the stack script does not.

Coming from a HyperCard background, where once an object's script 
handlers exceeded 30k of text one had to find inventive places to 
place "overflow" handlers, I am well versed at searching the places I 
might routinely use for handler storage;  however there is nothing to 
prevent one from always placing those handlers in the script of the 
first card, SO LONG AS the stack always opened at the first card.

Other workarounds:

* Lock messages before opening subStacks

* Trap the messages in the subStack script:

        on openStack
        end openStack
Perhaps the latter workaround would appeal to you, as every one of 
your stacks & substacks would include an openStack handler, null or 
not.
--

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution