Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!ux1.lbl.gov!beard
From: beard@ux1.lbl.gov (Patrick C Beard)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MultiFinder & Modal Dialogs
Message-ID: <1678@helios.ee.lbl.gov>
Date: 13 Jan 89 05:13:00 GMT
References: <2299@ilium.cs.swarthmore.edu>
Sender: usenet@helios.ee.lbl.gov
Reply-To: beard@ux1.lbl.gov (Patrick C Beard)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 54

In article <2299@ilium.cs.swarthmore.edu> jackiw@swatsun.UUCP () writes:
>In article <482@pyuxf.UUCP> asg@pyuxf.UUCP (alan geller) writes:
>> 
>> My question, though, is:
>> 	WHY can't layer switches happen when a modal dialog is displayed?
>
>Now, imagine if MF were to snatch control out from the
>get-event-requests which are presumably buried in the call to _ModalDialog.
>There are no problems giving time to other tasks, and this is what MF does.
>If, however, it allowed another layer to come frontmost, that would corrupt
>the windows in the _ModalDialog layer.  Now if User drags or resizes or closes
>a top-layer window, portions of the windows in the layer with the modal are
>going to be exposed, and consequently require updating in their back layer.
>Normally, MultiFinder would (TASK-)switch the app in, feed it its update
>events, and (TASK-)switch back to the frontmost layer. 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);
                ^^^^^^^^^^

All normal event processing can be done from within this code.  If you
write your application like this:

	main()
	{
		EventRecord evt;

		StartupMac();	/* init managers */

		do {
			if(GetNextEvent(everyEvent, &evt)) {
				ProcessEvents(&evt);
			} else {
				IdleAwayTheHours();
			}
			SystemTask();
			/* of course it's easier to call WaitNextEvent... */
		} while(!quit);

		CloseUpShop();	/* deallocate everything */
	}

Then from within your filterProc you just call ProcessEvents() when
appropriate.

Sorry for my longwindedness.

Patrick Beard
Berkeley Systems, Berkeley CA