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.