Path: utzoo!attcan!uunet!cbmvax!vu-vlsi!swatsun!jackiw From: jackiw@cs.swarthmore.edu (Nick Jackiw) Newsgroups: comp.sys.mac.programmer Subject: Re: MultiFinder & Modal Dialogs Message-ID: <2311@ilium.cs.swarthmore.edu> Date: 16 Jan 89 18:10:58 GMT References: <2299@ilium.cs.swarthmore.edu> <1678@helios.ee.lbl.gov> Reply-To: jackiw@ilium.UUCP (Nick Jackiw) Organization: Visual Geometry Project, Swarthmore College, PA Lines: 33 In article <1678@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: > In article <2299@ilium.cs.swarthmore.edu> jackiw@swatsun.UUCP () writes: > >In article <482@pyuxf.UUCP> asg@pyuxf.UUCP (alan geller) writes: > >> WHY can't layer switches happen when a modal dialog is displayed? > >THE WHOLE PROBLEM: > >The modal app CAN'T PROCESS ITS UPDATES... > Untrue. You are forgetting the parameters that are passed to ModalDialog: > pascal void filterProc(); > short int itemHit; > ModalDialog(filterProc, &itemHit); > ^^^^^^^^^^ > Then from within your filterProc you just call ProcessEvents() when > appropriate. > Patrick Beard You're right, but what I wrote IS true. Of course it's possible to code an app so that MF can switch out from modal situations. Elsewhere in my article I mentioned exactly that possibility. The vast majority of apps written in Multifinder times and ALL apps written before it, however, are NOT going to implement a filterProc to process updates for non-modal windows. Before Multifinder, this was considered an impossible occurence. We were talking about why MFinder's backward-compatibility enforces total modality, not about what tricks wonder-boy can teach wonder-app with total retrospective knowledge of the inner workings of an elaborate and elegant multiprocessing kludge. Follow before ya flame. -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ PER ASPERA AD ASTRA