Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!lsr From: lsr@Apple.COM (Larry Rosenstein) Newsgroups: comp.sys.mac.programmer Subject: Re: Showing a list of all the available windows Message-ID: <7525@apple.Apple.Com> Date: 1 Mar 88 23:28:10 GMT References: <8266@eleazar.Dartmouth.EDU> Reply-To: lsr@apple.UUCP (Larry Rosenstein) Organization: Advanced Technology Group, Apple Computer Lines: 46 In article <8266@eleazar.Dartmouth.EDU> matthews@eleazar.Dartmouth.EDU (Jim Matthews) writes: > >Another approach, used in a program developed here and (I believe) MacApp, >is to rebuild the windows menu whenever the user clicks on the menu bar. >Since there are no cmd-key equivalents that's the only time it needs >to be right, and it doesn't take enough time to slow the menu response >significantly. Just to elaborate. In MacApp we wanted to centralize all the menu setup in one methods (which might be implemented in several objects). It is certainly more efficient to change the menu state at the pooint in the program where you notice the change. In the case of a Windows menu, you add a new item when you create a window, check the appropriate item when you activate, etc. In MacApp, all menu setup is put into a method called DoSetupMenus. Various objects in the system implement this method, and each of those objects get a chance to setup the items it cares about. As was mentioned above, you setup the menus when the user clicks in the menu bar. In order to handle command keys properly, you have to do this when the user types a command key as well. The other case you have to handle is disabling a menu title. It would not be reasonable for the user to click on a menu title and then have it become gray. If you need to support this in an application, then you have to setup the menus after each event. In MacApp we remember if the menus are already setup so that excess work is not done. For example, if the menus were setup because the application is idle, then they don't need to be setup when the user clicks in the menu bar. Also, the programmer can define menus that are not managed by MacApp, and these can be setup in any way s/he chooses. Another approach is one mentioned in Scott Knaster's first book. You define an application event that means "menu update". Then when a window is created/destroyed or an activate/deactivate event is seen, you post a menu update event. In your main event loop, you can update all the menus when this event is seen. (You will have to be careful about posting more than 1 menu update or clearing out other pending menu updates after the first.) -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr