dubois@uwmacc.UUCP (Paul DuBois) (07/24/86)
There is a bug in ZoomIdle.
When it starts up, it saves the current menu bar, then replaces it with
an empty one. The reason for this is that when the main application
gets a mouseclick in the menu bar it calls MenuSelect, which retains
control until the mouse is released, then passes the selection to the
application. When the menu bar is empty, the only effect is to halt
the display while MenuSelect is tracking the mouse.
The problem: many aplications change the menu bar when a DA window
comes up in front. Most just dim menus, like MacWrite. That's ok.
BUT: if the application is such that it destroys its menu entirely
when a DA comes up in front, and recreates it when the DA goes away or
in back, then there's trouble in River City. If ZoomIdle emptied the
menu bar upon receipt of the activate event for its window, things
would be all right, because by the time it gets the activate event, the
previous active window will have been deactivated and can do what it
likes with the menu bar. What I did was clear the menu bar
*immediately*. This means that the application destroys its menu and
probably does a DeleteMenu to take the menu name out of the menu bar -
which is no longer the right menu bar. When ZoomIdle goes away, it
replaces the menu bar, which now has a bogus item - a name attached to
NO MENU.
I discovered this with TransSkel, since I typically write window
handlers that create and destroy menu handlers when the window is
activated/deactivate. However, I believe that this might also
account for ZoomIdle crashes when running ResEdit, because that also
makes menus disappear entirely, e.g., when a DITL window is deactivated.
Anyway, it's being fixed. The next version will also work with Mac XL
screens - something that's so simple I should have put it in the first
one.
--
Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois |
ARPA: dubois@easter --+--
|
Begin at my sanctuary... |
Ezekiel 9:6