Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!dino!uxc.cso.uiuc.edu!news
From: dorner@pequod.cso.uiuc.edu (Steve Dorner)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Windows menu and DrawMenuBar
Message-ID: <1989Aug21.165225.14091@uxc.cso.uiuc.edu>
Date: 21 Aug 89 16:52:25 GMT
References: <8320@hoptoad.uucp>
Reply-To: dorner@pequod.cso.uiuc.edu (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Lines: 26

In article <8320@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
>   ...  Like many other programs, mine do a complete menu item
>enable/disable pass whenever the application detects a menu bar click.
>Theoretically, it could be done at some other time more efficiently,
>but the code would be harder to maintain.  It's better to have all the
>related code grouped together in time and space.

I keep the related code together by having a routine called EnableMenus,
that I call whenever I need to, or every time the event loop runs.

It enables/disables menu items based on the program's current state, which
is mostly the kind and state of the topmost window (e.g., if the topmost
window is dirty, enable File:Save, etc.).  Also, the amount of state
information is small enough that I can save it each time through; if the
state hasn't changed since last time, I can skip the updating process.
Finally, there exists a flag in EnableMenus that can be set when I determine
that the menu bar needs to be redrawn.  The last thing EnableMenus does is
call DrawMenuBar if the flag is set.

This seemed to me to be a good compromise between efficiency and ease of
programming.  It's sort of ugly and inelegant, but that's just another way
of saying it was done on a Macintosh, isn't it? :-)
-- 
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: {convex,uunet}!uiucuxc!dorner
IfUMust:  (217) 244-1765