Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!batcomputer!munnari.oz.au!uniwa!vax7!nlewispn
From: Lewis_P@cc.curtin.edu.au (Peter Lewis)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Disabling menus when DA's are closed
Message-ID: <7358.27d75ba5@cc.curtin.edu.au>
Date: 8 Mar 91 01:38:45 GMT
References: <1.27D17B52@mmug.edgar.mn.org> <3BRcy1w163w@shark.cs.fau.edu> <1991Mar6.074201.13324@nada.kth.se> <1991Mar6.174029.4706@ni.umd.edu>
Organization: Curtin University of Technology
Lines: 48

In article <1991Mar6.174029.4706@ni.umd.edu>, 
        zben@ni.umd.edu (Ben Cranston) writes:
> As I said in private mail to the original poster, I've approached this
> problem by writing a "fixmenu" routine that examines FrontWindow and
> typically branches into three cases.  In the case that FrontWindow is
> completely null (no windows on the screen at all) typically only OPEN and
> QUIT in the FILE menu get lit.  If FrontWindow is one of MY windows then
> I do whatever is necessary, if not then FrontWindow is a DA window and I
> setup the menus for that case.

This procedure can also examine any other state dependend information (eg,
what the application is doing at the moment, what features are enabled,
whether the document has been modified).

> I call "fixmenu" on every activate and deactivate event.  When the front
> window changes you should get one or the other most of the time.  The bad
> case is when there are none of your windows at all and a DA comes and
> goes.  I could not think of a better solution than calling "fixmenu"
> after EVERY call to SystemClick.  This causes the menu bar to blink with
> each DA click though.

As I explaned in Email to the orignal poster, I simple call this every time
round the event loop.  To avoid flicker, I keep a shadow of the 
editMenuEndabled state, and only redraw the menu bar if it changes. I
don't have any problem with flicker, and I work on a Plus, and I dont
have any speed problems (after all, the OS routines called in the fixmenu
(I call it SetMenus) are all VERY simple (read/write a field in a record)).

Clearly if you were inclined, you could track down all the places where
your internal state changes, and track FrontWindow, and only call fixmenus
when any of them changed, but its much simpler and less error prone to 
simply call it every time round the event loop.  One problem I did have,
was that I had not enabled suspend/resume events, so my app lit the edit
menu up when it was switched out (because someone elses document window
was there), and left it lit when I was switched back, even though there
was no window.  It dimmed as soon as an event occured, so enabling
suspen/resume events fixed up the problem).

HTH,
   Peter.
-- 
Disclaimer:Curtin & I have an agreement:Neither of us listen to either of us.
*-------+---------+---------+---------+---------+---------+---------+-------*
Internet: Lewis_P@cc.curtin.edu.au              I Peter Lewis
Bitnet: Lewis_P%cc.curtin.edu.au@cunyvm.bitnet  I NCRPDA, Curtin University
UUCP: uunet!munnari.oz!cc.curtin.edu.au!Lewis_P I GPO Box U1987
AppleLink: Guy Kawasaki for Apple President!    I Perth, WA, 6001, AUSTRALIA
Has anyone ever found someone who used a Mac and then Changed To a PC?