Location of Handlers that Trap Messages

[Gregory Lypny]

Thanks for your thoughtful response, Devin.  Except in the simplest  
of stacks, my intuition has always been to place handlers that trap  
messages in or close to the objects for which they are intended.  It  
may be for this reason that I've yet to encounter the group-as-a- 
background problem you describe.  However, the standalone problem  
that you also mention would never have occurred to me, so many thanks  
for the heads up.

	Gregory


On Tue, Jun 19, 2007, at 1:00 PM, Devin Asay wrote:

> Message: 4
> Date: Tue, 19 Jun 2007 09:32:10 -0600
> From: Devin Asay <devin_asay at byu.edu>
> Subject: Re: Location of Handlers that Trap Messages
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Message-ID: <E033B7D8-4B06-436C-92AC-2D4C46998FBB at byu.edu>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> 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