Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!twinkies.berkeley.edu!lippin
From: lippin@twinkies.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Disabling menus when DA's are closed
Message-ID: <1991Mar7.032411.20810@agate.berkeley.edu>
Date: 7 Mar 91 03:24:11 GMT
References: <3BRcy1w163w@shark.cs.fau.edu> <1991Mar6.074201.13324@nada.kth.se> <1991Mar6.174029.4706@ni.umd.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 37

In many articles, people write:
  <Ideas on ways to keep the menu enabling/disabling current>

The method I've found best for doing this is:

1)	Keep a "menus may be out of date" flag.

2)	Have a routine which checks the flag, and when it is set,
	updates the menu enablements and clears the flag.

3)	After an event which may change the enablements, set the flag.
	(Which events are included here depend on the application.
	For example, if you disable cut/copy/clear when a text
	selection is empty, clicks and keys can change it.  It's
	probably best to be liberal here, except for null events, as
	might be needed for a "Stop" command.)

4)	If the flag is set, use a zero sleep time in WaitNextEvent.

5)	On a null event, if the flag is set, call the updating
	routine, and go back for another event.

6)	When you get a click in the menu bar or a command key, call
	the updating routine before handling it.

This method ensures that, no matter how complex your menu enabling is,
most actions aren't slowed down by it, because the updating is done at
idle time.  The fourth clause ensures that the user won't be looking
at out of date menus while deciding what to do next, and the sixth
clause ensures that the menus are up to date when they're actually
used.

					--Tom Lippincott
					  lippin@math.berkeley.edu

       "But let me repeat myself, at the risk of being clear:
	There must be fifty ways to write your program."