Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!apple!well!wdh
From: wdh@well.UUCP (Bill Hofmann)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MultiFinder & Modal Dialogs
Message-ID: <10404@well.UUCP>
Date: 19 Jan 89 00:24:53 GMT
References: <2299@ilium.cs.swarthmore.edu> <1678@helios.ee.lbl.gov> <2311@ilium.cs.swarthmore.edu>
Reply-To: wdh@well.UUCP (Bill Hofmann)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 22

In article <2311@ilium.cs.swarthmore.edu> jackiw@ilium.UUCP (Nick Jackiw) writes:
>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?

Because Multifinder won't switch when a window of type dBoxProc, the
standard modal dialog or alert window, is frontmost.  As I understand it,
this was a deliberate decision to improve backward compatability.

>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.  

Beg to differ.  If your modal dialog does something like put up an SFGet
or SFPut, you could easily have to deal (or want to deal) with update
events.  My standard filterproc handles updates.

-Bill Hofmann