Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!amdahl!apple!dwb
From: dwb@Apple.COM (David W. Berry)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MultiFinder switch bug with custom WDEFs
Message-ID: <9445@apple.Apple.Com>
Date: 9 May 88 22:04:51 GMT
References: <242@uvabick.UUCP> <8700@apple.Apple.Com> <2887@midas.TEK.COM> <9332@apple.Apple.Com> <2770@polya.STANFORD.EDU> <9364@apple.Apple.Com> <2781@polya.STANFORD.EDU>
Reply-To: dwb@apple.UUCP (David W. Berry)
Organization: Apple Computer Inc, Cupertino, CA
Lines: 43
Keywords: MultiFinder doesn't allow switching when it thinks it sees a dBoxProc

In article <2781@polya.STANFORD.EDU> kaufman@polya.stanford.edu (Marc T. Kaufman) writes:
>OK, I agree that GetNewDialog and NewDialog can be used for modeless dialogs,
>but the important thing is that the DLOG resource has no way of specifying
>a window type other than modal-dialog.  I HAVE used these routines to start
>a modeless dialog, by setting the initial window to invisible, then changing
>the window type in the dialog before showing the window for the first time.
>However, and here is the catch, if you make the window a non-dialog type
>(so that Multifinder will switch -- remember that multifinder doesn't care
>how you USE the window, only its type), then IsDialogEvent will always
>return FALSE -- because IsDialogEvent goes through the Window list looking
>for MODAL DIALOG windows.
	Well, two problems here:
	1.  The correct way of setting the window type when creating
	a dialog is to via procID argument to NewDialog.  The DLOG
	resource has a similar field at offset 8, so it works with
	GetNewDialog too.
	2.  IsDialogEvent does *not* look for modal dialog windows.  It
	look for windows with windowKind == dialogKind.  Works out
	quite well since NewDialog and GetNewDialog both set windowKind
	to dialogKind.
>Now... how do you do the IsDialogEvent function without writing a whole
>event loop -- which is why you use ModalDialog in the first place.?
	Huh?  If you're saying you are using ModalDialog to avoid putting
an event loop in your program at all, go ahead, you're program isn't
very macintosh anyway so why bother.  If you're claiming that using
modeless dialogs requires a separate event loop, you're way off base.
It merely requires the addition of a few lines to your existing
event loop, a few subroutines to deal with button clicks and the like
(the code would be needed for modal dialogs also) and a few globals to
keep track of what dialogs are currently displayed and active.

	Get a hold of the version of TransSkel which has been modified
to work with modeless dialogs.  It works.  It will show you how these
things ought to be done.  It may even save more argument here :-)
>
>Marc Kaufman (kaufman@polya.stanford.edu)


-- 
David W. Berry
dwb@Delphi	dwb@apple.com	973-5168@408.MaBell
Disclaimer: Apple doesn't even know I have an opinion and certainly
	wouldn't want if they did.