Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!amdahl!pyramid!voder!apple!goldman
From: goldman@Apple.COM (Phil Goldman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MultiFinder switch bug with custom WDEFs
Message-ID: <8687@apple.Apple.Com>
Date: 20 Apr 88 18:03:43 GMT
References: <242@uvabick.UUCP>
Reply-To: goldman@apple.UUCP (Phil Goldman)
Organization: Apple Computer Inc, Cupertino, CA
Lines: 25
Keywords: MultiFinder doesn't allow switching when it thinks it sees a dBoxProc

In article <242@uvabick.UUCP> thomas@uvabick.UUCP (Thomas Fruin) writes:
>MultiFinder won't let you switch when there is a modal dialog box open
>on the screen, since the user is expecting a modal situation.  To determine
>this, MultiFinder looks to see (among other things) if the window definition
>procedure of that window is dBoxProc.  (I'm quoting Technical Note 180 here)
>...
>Sadly, MultiFinder ignores the resource ID completely.  So if anybody out
>there is using custom WDEFs, make sure to avoid variation code 1.  It was
>a weird experience not being able to switch at all, even though I had
>document windows on top.


This is not a bug, but merely an oversight in not documenting the conditions
completely.  dBoxProc is reserved for modal dialogs, no matter what the
WDEF is.  This is necessary because we have to allow for the system (or even
an app) to easily patch the standard WDEF by adding some code to the front
and then falling thru to the standard one.  This would cause problems if we
checked the resource ID too.

The reason that all of this checking is necessary in the first place is
because some applications will put up a modal dialog without actually calling
the trap _ModalDialog to handle it.  If it always was called we probably
would not have looked at the var code at all.

-Phil Goldman
Apple Computer