I have hacked something together that works cleanly and certainly
makes the symptom we had go away.
I normally try very hard to avoid modifying system classes, but in
this case I'm looking at this as fixing a fairly fundamental problem.
So, this fix involves adding an instance variable and a few methods to
ApplicationWindow.
The gist of the fix is that I have implemented >>addEvent: in
Applicationindow to evaluate a block when it gets an event. The
default block does the same thing as Window>>addEvent, and there are
two other pre-defined blocks that block all events and block
everything except damge (reveal) events.
As Terry pointed out, one factor in dealing with this is the amount of
work the parent window chooses to do between receiving the event
requesting a dialog, and the dialog instance being created. In our
case, this work included some IO, and this allowed plenty of time for
users to sneak in extra events by whacking the keyboard or wobbling
the mouse.
Anyway, the fix in practice when used looks something like this:
openTheDialogNowDamnit
"^self
I open a dialog in such a way that I avoid getting unwanted events."
self mainWindow doWhileHandlingOnlyDamageEvents: [
self doLotsOfSlowIO.
(MyDialogClass newFor: aModelObject) openAsDialog].
^self
The reasoning for making the fix in ApplicationWindow is as follows:
All the events for a given ApplicationWindow flow through the object
via >>addEvent: . Making the change here seems to be cohesive because
it's really is the window that we want to have ignore the events.
Anyway, it seems to work but I fear I may have been naive in some way.
Comments appreciated.
Thanks,
Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
Locked
