straka@ihlpf.ATT.COM (Straka) (06/27/88)
In article <1128@aucs.UUCP> peter@aucs.UUCP (Peter Steele) writes: >When using MacLink/Plus while the ApplicationMenu init is loaded it >is not possible to access the menu bar. Any attempt to pull down a >menu brings up the application list at the point of the click. Furthermore, This problem also occurs with FastFormatter2.2 (and ApplicationMenu1.0). The menu bar is non-functional, but the ^Q quit still works. -- Rich Straka ihnp4!ihlpf!straka Avoid BrainDamage: MSDOS - just say no!
lsr@Apple.COM (Larry Rosenstein) (06/29/88)
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!lsrt-benw@microsoft.UUCP (Benjamin Waldmin) (06/30/88)
In article <12996@apple.Apple.COM> lsr@apple.apple.com.UUCP (Larry Rosenstein) writes:
I seem to have missed the posting of version 2.0 of this INIT. Could someone
mail me a copy?
Thanks a lot,
Ben Waldman
!uw-beaver!microsoft!t-benw
Disclaimer: My thoughts, opinions, and requests only (and what do I know?)