Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!purdue!decwrl!labrea!polya!kaufman
From: kaufman@polya.STANFORD.EDU (Marc T. Kaufman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MultiFinder switch bug with custom WDEFs
Message-ID: <2770@polya.STANFORD.EDU>
Date: 6 May 88 15:48:33 GMT
References: <242@uvabick.UUCP> <8700@apple.Apple.Com> <2887@midas.TEK.COM> <9332@apple.Apple.Com>
Reply-To: kaufman@polya.stanford.edu (Marc T. Kaufman)
Organization: Stanford University
Lines: 24
Keywords: MultiFinder doesn't allow switching when it thinks it sees a dBoxProc

In article <9332@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes:
>In article <2887@midas.TEK.COM> herbw@midas.UUCP (Herb Weiner) writes:

.>Perhaps someone could explain the rationale for PROHIBITING a context switch
.>when a modal dialog box is in front...

>The rationale is one of user interface.  A modal dialog should be used when the user must interact with it before the (visible) task can continue.  If this is not its purpose, then the dialog should be modeless.

.>Perhaps what I'm really suggesting is that modal dialogs are only modal
.>with respect to that application that displays them, but that they should
.>be MODELESS with respect to OTHER applications running under MultiFinder.

>There might be some use for dialogs that are modal within their layer.
>This can already be accomplished by the applications themselves.  Hopefully
>these will not too often be used.

One of the main reasons for using modal dialogs where modeless dialogs
would do, is the availability of the Dialog Manager for handling most of
the buttons, switches, and events.  If a dialog is modeless, you cannot
use IsDialogEvent, NewDialog, GetNewDialog, or the ModalDialog event filter.

Provide these tools for modeless dialogs, and more people would use them.

Marc Kaufman (kaufman@polya.stanford.edu)