Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!samsung!usc!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!jk3t+
From: jk3t+@andrew.cmu.edu (Jonathan King)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Question about protocol for trapping menu items.
Message-ID: <8bdsGB_00WB4E=Yksu@andrew.cmu.edu>
Date: 31 Jan 91 02:44:29 GMT
References: <1982taylorj@yvax.byu.edu>
Organization: Psychology, Carnegie Mellon, Pittsburgh, PA
Lines: 45
In-Reply-To: <1982taylorj@yvax.byu.edu>

taylorj@yvax.byu.edu writes:
> In <48422@apple.Apple.COM>, jdevoto@Apple.COM (Jeanne A. E. DeVoto) writes:
> 
> >  on doMenu theItem
> >    if theItem is "Compact Stack" then
> >      close window "MyPalette"
> >      send "doMenu Compact Stack" to HyperCard -- avoids recursion
> >      palette "MyPalette", "345,80"
> >    else pass doMenu
> >  end doMenu
> 
> Ok, but what if you're the top stack in the stacksInUse and there's 
> another stack below you that also has a doMenu handler that closes 
> its windows?  If you send the command straight to HyperCard the
> other stacks never get it.  

Yup.  I pointed this out, too, in my response to this message.  And
the problem isn't just limited to stacks in use; it could occur
anywhere you send a message to Hypercard.  But it's a particular
problem when possibly several different handlers along the message
path have to handle a message or Bad Things happen.

> I've been wrestling with this general problem (passing on a message 
> so other stacks get it but still doing something after the message 
> is "finished") and I haven't come up with a good solution.  I've 
> resorted to setting a global flag and checking it in an idle handler, 
> but I don't really like doing it that way. Would it be better to
> find my stack's place in the stacksInUse list and send
> the message on to the following stack?  Any suggestions?

I've come to the decision that too many global flag/ idle handler
combos are a Bad Thing, although they can be unavoidable sometimes.  I
once started writing a function nextobject(current object) that would
return the next object in the message passing hierarchy given the name
of the current object, but it got pretty hairy and inelegant.  You had
to chase down the background of a card, (not too hard, but it isn't
included in the long name of the card), test if you were "Home", maybe
sort through the stacksinuse...I just didn't want to do the general
case badly enough.  And anyway, it seemed really obvious that there
should be something like "the next handler" in the language itself to
cover this situation: send "foo" to the next handler.

Any chance of seeing this in a future version of Hypercard?

jking