Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Help!
Message-ID: <7308@goofy.Apple.COM>
Date: 21 Mar 90 02:05:45 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 30
References:<45183.25FD20CE@cmhgate.FIDONET.ORG> <25ff4e70.643e@polyslo.CalPoly.EDU> <14463@reed.UUCP> <2735@hudson.acc.virginia.edu> <1990Mar21.000232.18637@athena.mit.edu>

In article <1990Mar21.000232.18637@athena.mit.edu> rrkasegu@athena.mit.edu 
(Rick R. Kaseguma) writes:
> Wait!  Why don't you just head patch MenuSelect?  The point where the
> user clicked will be on the stack, and you won't be slowing everyone down

This would be the right solution, except that there are programs out there 
that pass the address of the mouse point instead of the point itself. 

(The reason the Menu Manager works is that it immediately enters its loop 
tracking the mouse and quickly gets the correct coordinate.)

So if you do patch MenuSelect, you should independently get the mouse 
position, and not rely on the validity of the parameter passed to 
MenuSelect.  The next question is how to get the mouse position.  You can 
call GetMouse, but you have to realize that this converts the global 
position into a local coordinate.  

In my ApplicationMenu init, I used to call OSEventAvail, since it fills in 
the event record with the current global mouse position.  Unfortunately, 
this caused an incompatibility (at one point) with QUED/M.  (Apparently 
they patch MenuSelect and one of these traps, and their patches weren't 
reentrant.)

Now I simply access the Mouse low memory global.  (I'm so embarrassed! :-)

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1