Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!pacbell.com!ames!haven!ni.umd.edu!ni.umd.edu!zben
From: zben@ni.umd.edu (Ben Cranston)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Disabling menus when DA's are closed
Summary: Another check when windows close
Message-ID: <1991Mar11.173337.1044@ni.umd.edu>
Date: 11 Mar 91 17:33:37 GMT
References: <1991Mar6.174029.4706@ni.umd.edu> <4017@uakari.primate.wisc.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland at College Park
Lines: 36
Nntp-Posting-Host: ni.umd.edu

In article <4017@uakari.primate.wisc.edu> bin@primate.wisc.edu writes:

> Do also have the problem that when you have only one window and it goes
> away, there is no deactivate?  When I've tried to solve this problem,
> I think I ended up having to mess with menus on activates/deactivates
> and window closes.  It's an ugly problem.

Paul brings up a very good point.  If there is exactly one window on the
screen and it is CLOSED (i.e. destroyed) there will be no deactivate event
because it is not going to the back, it is going AWAY.  Since there is no
other window to be brought forward, there will be no activate event either.
But, you still need to get the menu enables updated.  I suppose you could
put a call to FixMenu in whenever you close a window, but then the problem
of detecting a close to a Desk Accessory comes up again.  Expecially if the
Desk Accessory can "close itself", maybe with a button the application
cannot know about or even an explicit call to CloseDeskAcc from within itself.

The alternative of checking for a changed FrontWindow() in the main event
loop and keeping track of the menu state really changing to supress blinking
starts sounding better and better.

> There's no need to make the menu bar blink unnecessarily, though.  Check
> bit 0 of the menu flags word to see what the state of a menu is, *then*
> figure out what it *should* be.  If they differ, then you need to redraw
> the menu bar after the menu and its items are set properly, otherwise you
> don't need to.  This way, the menu bar blinks only when a menu state changes.

If you're careful you can do this with just two flags rather than one flag per
menu.  One saves the pre-modification state of the menu you are currently
updating, if the update changes the state of the menu the second flag gets set.
At the end, if the flag is set, you need to do a DrawMenuBar.

N.B. it looks like from a close reading of the Window and Event manager
chapters that you actually DO see activate and deactivate events for DAs
but GetNextEvent returns false, so an event loop that requires a true response
would never notice them.