Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!icdoc!qmw-cs!jeremyr
From: jeremyr@cs.qmw.ac.uk (Jeremy Roussak)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Dialog from a Trap
Message-ID: <2198@sequent.cs.qmw.ac.uk>
Date: 8 May 90 20:15:35 GMT
References: <21747@dartvax.Dartmouth.EDU> <11282@hoptoad.uucp>
Reply-To: jeremyr@cs.qmw.ac.uk (Jeremy Roussak)
Organization: Computer Science Dept, QMW, University of London, UK.
Lines: 41

In article <11282@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>
>Yet another:  Don't *call* the old GetNextEvent -- that's a tail
>patch.  Your routine should do something like returning to an outer
>shell of assembly language, popping the stack frame back to its state
>when you were called, and jumping to the old routine address.  A
>popular way of doing this last part is to push the old address and then
>RTS, but I always put the old address into a scratch register and jump
>to it instead (if I can -- beware of register-based traps).
>
>Personally, if I were doing this, I'd go ahead and do a tail patch,
>but do it on InitDialog and forget the whole GNE/WNE charade: it's
>too complicated.  How can I actually recommend a tail patch?  Simple --
>InitDialogs is called in one very well-defined place, from an application
>startup.  The chance of it being called by any system software, and so
>the chance of acquiring a come-from check which would screw up a tail
>patch, is so slim as to be worth forgetting.  So call the old InitDialogs
>first, forget about unpatching, and then go on and call your mysterious
>one-per-launch dialog before returning from your InitDialogs patch.

Tim raises an interesting point here: is it *ever* OK to tail patch?

The reason I'm interested is that I want to write (well, have written
in fact) an INIT that intercepts a menu selection from a certain
application and does something else when a particular item is chosen.

Now, the easy way to do this is to tail patch MenuSelect, and this is
what I've done.  I know about all the no-nos, but it works (at the moment).

The difficult way, it seems to me, is to write a jGNEFilter patch
that detects mouseDown events, find out where they are and simulates
MenuSelect.  Seems tedious, boring and rather like re-inventing the
wheel: if there's a perfectly good MenuSelect routine already in my
Mac's ROM, why should I write another?

All advice gratefully received, and comments welcome.  No flames, please.

Jeremy Roussak

and no, it's not the sound-on-emptying-the-trash again (for anyone who
remembers the last tail patching flame wars)