Location of Handlers that Trap Messages

[Devin Asay]

On Jun 19, 2007, at 6:36 AM, Gregory Lypny wrote:

> Hello everyone,
>
> I'm a little rusty here.  Does it matter much where I place  
> handlers that trap openCard, closeField, and such messages?  In a  
> simple stack, I put them all in the stack script, but I guess I  
> could put them in group script.  I'm interested in speed as opposed  
> to which controls will receive a message because they lie in its path.

Hi, Gregory.

My rule of thumb (thanks to Jerry Daniels for stating it in a  
succinct formula,) which I pass on to my students is:

"Place a handler as far up the message hierarchy as it needs to be,  
but no farther."

In other words, if several controls do virtually the same thing, a  
handler placed in an enclosing group or a card might be the most  
efficient placement. On the other hand, don't just throw all of your  
handlers in a stack script, since not all handlers are needed  
everywhere in the stack.

In fact, a handler placed too far up the hierarchy can have the  
unintended effect of being triggered too often. I see a common  
problem in beginner stacks that starts to show up right after I  
introduce groups, and I urge students to place handlers in the group  
script rather than in individual buttons within the group, when  
appropriate. So often what happens is students rightly create a group  
of navigation buttons with, say, a "go next" button, that is to be  
placed on every card. Then they put a mouseup handler in the group,  
something like this:

on mouseUp
   go next card
end mouseUp

But what happens if the group inadvertently gets set to be a  
backgroundBehavior group (which happens often; see the "undocumented  
feature" described in <http://quality.runrev.com/qacenter/ 
show_bug.cgi?id=1197> .) Suddenly every click on any object on the  
card, or even on the card itself, can trigger mouseUp in the group,  
unless those objects have their own mouseUp handler. A much better  
placement, of course, is in the "next" button itself, since no other  
control really needs to trigger that action. This is maybe a  
simplistic example, but it's a good illustration of what can happen  
if you expose a handler to too many objects by placing it too high in  
the message hierarchy.

More insidious are preOpenStack and openStack handlers placed in the  
stack script of a stack that is used to launch other stacks. In the  
IDE everything is fine. But as soon as you  create a standalone from  
that stack, it essentially becomes the Rev engine, and every stack it  
opens will potentially pass openStack messages up to it. As someone  
else mentioned, you can avoid this problem by placing these handlers  
in the card script of card 1 of the stack, but even that can lead to  
unintended consequences.

Regards,
Devin


Devin Asay
Humanities Technology and Research Support Center
Brigham Young University