Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Windows menu and DrawMenuBar
Message-ID: <15093@dartvax.Dartmouth.EDU>
Date: 18 Aug 89 07:02:00 GMT
References: <8320@hoptoad.uucp>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 70

In article <8320@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
>I'd like to have some discussion on the proper maintenance of a Windows
>menu.  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.

     The problem with doing this at menu bar click time is that if you
have a large amount of menu housekeeping to do then you might slow
down your reponse time to the menu bar click.  If there is too much of
a delay before your menus drop down then your program will be
perceived as having performance problems.  And the worst offender is
probably the next subject you mention...

>So anyway.  Another thing I do at the same time is rebuild my Windows
>menu.  This is a pretty simple piece of code which first truncates the
>Windows menu down to a fixed header of generic window operations
>("Stack", "Tile", "Next", "Previous"), then appends all the window
>titles, iterating down the window list starting at FrontWindow().
>
>The problem is that under System 6.0, it is neccessary to call
>DrawMenuBar after adding any items to a menu.  If you don't, they will
>not be visible to the user during MenuSelect.

     I have not observed this behavior.  I am running 6.0.3 on a Mac
II and on a Plus, and find that I can add or delete menu items with
impunity without calling DrawMenuBar.  I do not get menu items which
are not visible.  I wish you would give more information about this
problem, since what you have written above makes me worry that I am
missing something.  I also dug out a 6.0 disk and tried it with the
same result:  No need to call DrawMenuBar.

     What I have observed, in my programs and apparently in other
people's programs, is that when you have one of these window menus you
can visibly slow down response time by having a large number of
windows open.  Rebuild that window menu every time, and you get a
perceptable wait between the time you click and the time you first see
a menu.

     I saw one solution to this problem at MacWorld Expo, at the
DayStar Digital* booth.

     For those of us who cannot afford this solution, one has to
resort to optimizing the software.  Rebuilding menus any time a change
occurs which can affect their appearance might be one way to improve
response to mouse clicks in the menu bar, but it has one serious
disadvantage that I can think of.  Many of the changes you make will
never be seen, since these will be overridden by later changes.  It is
also a bear to code this way if there are many things in the menus
which need changes, and many events which require them.

     Another solution is to maintain some kind of data structure which
reflects the validity of menus in your program that you determine by
testing to be performance offenders.  Reset all your validity flags
when you rebuild the menus, set them when events occur which call for
a change in menu appearance.

     Some percentage of the time, you will get lucky.  For instance,
it is certainly possible to have the user do things which will not
change the window ordering, and therefore will not invalidate your
window menu.  If you have a flag that you set every time something
happens to change the window list, then you will know whether to
rebuild the window menu before calling MenuSelect or not.

Earle R. Horton

*DayStar Digital makes a 50 MHz accelerator containing a 68030.  Eat
your heart out if you cannot afford one.  Chuckle at the rest of us if
you can.