Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!edcastle!lfcs!nick From: nick@lfcs.ed.ac.uk (Nick Rothwell) Newsgroups: comp.sys.mac.programmer Subject: Re: Windows menu and DrawMenuBar Message-ID: <193@castle.ed.ac.uk> Date: 21 Aug 89 11:21:15 GMT References: <8320@hoptoad.uucp> Sender: root@castle.ed.ac.uk Reply-To: nick@lfcs.ed.ac.uk (Nick Rothwell) Organization: LFCS Enya Admiration Society Lines: 42 In-reply-to: tim@hoptoad.uucp (Tim Maroney) In article <8320@hoptoad.uucp>, tim@hoptoad (Tim Maroney) writes: >I'd like to have some discussion on the proper maintenance of a Windows >menu. >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 think this comes from the beginning of time (viz. Inside Mac I), rather than being anything new and System-6.0-ish...? I use Paul duBois' TransSkel, and attach actions to ACTIVATE and DEACTIVATE and so on. When a window activates or deactivates, it alters its own menu item in the window menu, adding a tick or whatever. A similar thing happens for creating and disposing of windows. I essentially implement a lazy update. I have routines for (i) putting in a windows menu, (ii) taking out a windows menu, and (iii) updating the menu bar. There's a cache saying whether there's a window menu or not (in fact, there's a menu ID here, because I have a number of windows menus with different titles, depending on "mode", whoops, pardon me, dirty word...). When a window deactivates, it removes the menu but doesn't do an update. When a window appears, it adds a windows menu, and re-draws the menu bar if the menu title is different to the old one. It looks pretty smooth. >(including deactivate); if that fails, then I'm going to have to put in >a call to the update windows menu routine whenever a window is created >or destroyed, and I really do not want to do that. Any reason why not? I have everything driven from the create/destroy/activate event handlers, and the structure doesn't seem too bad. >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk !mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Fais que ton reve soit plus long que la nuit.