Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!samsung!uakari.primate.wisc.edu!zazen!schaefer.math.wisc.edu!dickie From: dickie@schaefer.math.wisc.edu (Garth Dickie) Newsgroups: comp.sys.mac.system Subject: Re: True Multitasking Message-ID: <1991Jan19.231148.11013@schaefer.math.wisc.edu> Date: 19 Jan 91 23:11:48 GMT References: <19019@shlump.nac.dec.com> <48122@apple.Apple.COM> Reply-To: dickie@macduffe.math.wisc.edu (Garth Dickie) Organization: Univ. of Wisconsin Dept. of Mathematics Lines: 54 In article urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.sys.mac.system, article <48122@apple.Apple.COM>, > heksterb@Apple.COM (Ben Hekster) writes: >< >< If you want to experiment, you might try setting up MenuHook and >< DragHook to a little routine that calls WaitNextEvent, and see if performance >< is more to your liking. >< >Won't work. > >When an application gets background time, it may want to draw on the screen. >If your menu is directly over one of its windows, your menu will get severely >clobbered. > >The application may also want to add menus, and there _might_ be reentrancy >problems with the Menu Manager. > Just a side note: I tried this sort of thing once, just for kicks. It appears in a program called gadlife that never made it very far... You are right in that you can't call waitnextevent. But your own application can do some processing during the menu drags. There is not really a problem with response time if you take no more than a tick each time you get control, and the effect can be quite striking, if you do the extra work required to display properly while there is a menu onscreen: - capture the copybits from the screen done by the menu manager, so that you know the rectangle containing the menu. - every time you display, clip to the menu which is visible - capture the copybits *to* the screen, and update the contents of the bit/pix map to reflect your modified windows. there are two problems with this (besides the obvious 'dont patch traps'). First, there are heierarchical menus: gadlife handled this correctly. You simply keep a stack of information, etc; it all works out. The other is more subtle: if you are low on memory, the menu manager may not call copybits, accumulating update events instead. gadlife didn't handle this correctly, but I'm sure it would be possible. There are other problems with the whole approach: if something reflected in a menu item changes status during a menu selection, the menu should change, right? much violence is done to the user interface :-) Perhaps multifinder could (on request) send 'don't touch the screen' null events during screen muckiness. This would be appropriate for faceless tasks, for instance. -- ------------------------------------------------------------- Garth A. Dickie dickie@macduffe.math.wisc.edu