earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/20/89)
If you have a modeless dialog in front, and are MultiFinder
aware, then you will get suspend/resume events if MultiFinder is
active and the user swaps you into the background or out of it. It is
proper to activate/deactivate the modeless dialog under these
conditions. This is, of course, true for any window.
My problem comes when I call IsDialogEvent() after
WaitNextEvent(), and I have an app4Evt (suspend/resume).
IsDialogEvent() says this is a dialog event, so I pass it on to
DialogSelect(), expecting DialogSelect() to do the right thing.
Nothing happens, however, as far as activating/deactivating the dialog
goes. If it has an editText item, then it continues to blink away
happily even if another application's windows are frontmost.
It seems to me that DialogSelect() should have been patched to
recognize app4Evts, and should deactivate a modeless dialog when it
gets a suspend event for one, and reactivate when it gets a resume
event. It has not been patched, however, since MacsBug says it's in
ROM, and I think the ROM predates MultiFinder.
I can deactivate the dialog window myself in response to these
events, or I can change the app4Evt to an activateEvt and send it on
to DialogSelect(), but neither approach is clean, to my way of
thinking. I welcome clean solutions to this problem.
Is this a bug in MultiFinder?
Earle R. Horton