🚀 go-pugleaf

In article <127200007@inmet> lipsett@inmet.UUCP writes:
>
>This works fine in general.  However, when I throw an alert box up on
>the screen, deactivate events either are not generated for the windows
>covered by the alert box or else the alert box toolbox routine eats
>them.  As a result, when the alert box is dismissed, the resulting
>activate and update events lose badly, and either the windows are
>displayed wrong or I get a bomb of one kind or another.

The problem will appear with any modal dialog.  In a modal dialog, the
Dialog Manager is in control and receives the events.  If an event is
intended for a dialog window it can do something with it.  

If the event is for a non-dialog window, then it throws it away.  The
deactivate event for your window is such an event.  There's really not much
else it can do with such an event.  When the modal dialog goes away, your
application starts receiving events again, and one of the first it will get
is an activate event for its window

In MacApp, we took the approach someone else suggested, which is to keep
track of whether your application's window is already activated, and ignore
the "extra" activate.

If you want, you can catch the deactivate event by passing a filter proc to
the Alert or Modal Dialog call.  In the filter proc, you can call
IsDialogEvent, and if it returns FALSE (not a dialog event) pass the event
to your normal event handling code.

The only problem is that some calls to Alert/Modal Dialog don't come from
your application, which means you can't pass a filter proc.  You can,
however, create a global patch for the Modal Dialog trap which always passes
your filter proc in as a parameter.  (You will have to call the original
filter proc, if it exists.)

I did this once (a while ago), and it seemed to work.  I will try to dig up
the code, but I am not sure if it is around any longer.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

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