Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!claris!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: Problem with ApplicationMenu
Message-ID: <12996@apple.Apple.COM>
Date: 29 Jun 88 00:57:36 GMT
References: <1128@aucs.UUCP> <5121@ihlpf.ATT.COM>
Reply-To: lsr@apple.apple.com.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 53

I know of 2 bugs in ApplicationMenu 2.0, both of which can be worked around.
(I have gotten lots of reports about these recently, so I would post this
info.)

(1) If you have Suitcase installed, and select Desk Accessoires from the
ApplicationMenu popup menu, you will end up activating the last DA in your
list.  The problem is a conflict between ApplicationMenu and Suitcase
patching the same trap.  The workaround is to load ApplicationMenu after
suitcase, by renaming it to zApplicationMenu.

(2) If you do that, then you will notice that the Suitcase icon appears on
the screen twice at boot time.  The problem here is that ApplicationMenu is
displaying the wrong icon id.  Before renaming ApplicationMenu, the icon was
never found, and it would display nothing.  Afterwards, it displays the
Suitcase icon.

The workaround is to open ApplicationMenu with ResEdit.  Duplicate the
(only) ICN# resource in the file, and give the duplicate id 128.

Both of these bugs will be fixed in the next version.

There have also been reports of certain application in which clicking
anywhere on the menu bar activates ApplicationMenu.  I have only examined
one of these cases, but I believe that in each case, the bug is in the
underlying program.  

ApplicationMenu gets control when the application calls the MenuSelect trap.
MenuSelect is supposed to be passed the mouse point from the event record.
I believe that these applications are passing the wrong thing to MenuSelect.
(In the case I looked at, the program passed the address of the mouse point,
instead of the point itself.)

ApplicationMenu assumes the mouse point is correct and will activate itself
if the point is to the left of the Apple menu or the right of the
MultiFinder icon, which will always be true in the case of this bug.

There is no easy workaround for this.  It should be easy to patch the
application and fix its call to MenuSelect, but that is not a simple task.
The next version of ApplicationMenu will not use the point that is passed
in, but will get the current mouse position itself.

I don't know when the next version will be available.  Besides fixing these
bugs I would like to make it compatible with FullWrite and provide a way to
launch selected applications.  (If you have any other features you would
like to see, let me know.)

Sorry for the bugs.

		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 27-AJ  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr