Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!csd4.milw.wisc.edu!nic.MR.NET!umn-cs!berlin!sec From: sec@berlin.acss.umn.edu (Stephen E. Collins) Newsgroups: comp.sys.mac Subject: Re: multitasking and IPC Summary: Lies, Damn Lies! Message-ID: <270@berlin.acss.umn.edu> Date: 29 Dec 88 05:45:56 GMT References: <1988Dec16.191309.21623@cs.rochester.edu> <326@internal.Apple.COM> <6120@hoptoad.uucp> Organization: U of M MicroGroup, Minneapolis Lines: 33 In article <6120@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > No, other applications don't get time when a modal dialog is up. The way > MultiFinder senses modality is by checking then window definition procedure. > If a type dBoxProc is at the front, no other application will get time. This statement is incorrect. Other applications DO get time when modal dialogs are up. I'm sure you can think of many methods to easily establish this fact; A quick easy way: 1. Bring up your favorite trivial application with a new file, and make some changes in the window (MacPaint?) 2. Bring up the "Find File" DA, and start it hunting for a file that doesn't exist. (You can HEAR and SEE it grinding away) 3. Click back to your favorite application, and click in the window's close box, which will bring up a modal dialog along the lines of "Save your changes?" 4. Look at this modal dialog, type dBoxProc, at the front, and WATCH and LISTEN to "find file" grinding away in the background. However, this still doesn't change my opinion that it would be much more robust to implement pre-emptive multitasking. +-----------------------------------------------------------------------+ | Stephen E. Collins | sec@ux.acss.umn.edu / | ACSS Microcomputer & Workstation Systems Group | sec@UMNACVX.BITNET / | 125 Shepherd Labs +-----------+-------------------/ | University of Minnesota | Cum hanc intellegas, Latinam / | Minneapolis, MN 55455 | sententiolam potes legere! / +------------------------------------+----------------------------+