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.