Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!pyramid!voder!apple!lsr
From: lsr@apple.UUCP (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: Missing deactivate events
Message-ID: <6480@apple.UUCP>
Date: Thu, 15-Oct-87 13:13:32 EDT
Article-I.D.: apple.6480
Posted: Thu Oct 15 13:13:32 1987
Date-Received: Sat, 17-Oct-87 11:03:27 EDT
References: <127200007@inmet> <9262@ut-sally.UUCP>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 32

In article <9262@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes:
>
>     For your code, just do a deactivate (really a fake deactivate, see below)
>before you call an Alert.  Dialogs don't cause this problem because the
>activate/deactivate events are generated by [Get]NewDialog and not by
>ModalDialog.  There are exceptions to this, such as SFGetFile and SFPutFile.
>Those guys handle their "own" events, so you need to do a fake deactivate
>before calling them.

Dialogs are not completely immune from this problem.

The action of making a new window (dialog or not) frontmost will schedule a
pair of deactivate and activate events.  The next call to GetNextEvent will
return a deactivate event, and the following one an activate event.  

If ModalDialog makes the first call to GetNextEvent, it will throw away the
deactive, since it won't be directed to a dialog window.  If your code makes
the call, you can process the event normally.

In the case of alerts or Std File, it is not possible to run any of your
code between bringing up the dialog and calling ModalDialog.  In these
cases, you can use an event filter proc to catch the event.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com