Smalltalk › Cincom › VisualWorks

Opening a Dialog window from a button processes window events???

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 2 messages Options
Dennis smith-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Opening a Dialog window from a button processes window events???

Dennis smith-4
It seems that when you open a Dialog from an existing non-modal window, that it runs all window events just before the dialog opens.

Consider this case
  1. button on a window which goes away and does things for 2 seconds (I did "Delay 2")
  2. have a requestForWindowClose method that puts up a dialog asking if the window should be closed
  3. press the button
  4. during those 2 seconds, press the [x] close button on the window, this queues an event for the window
So, after the 2 seconds expire, the button code opens a Dialog, but prior to that the window-events are processed and the requestForWindowClose code is invoked which puts up its own dialog -- at which point the button's dialog opens.

We now have two dialog boxes open and the user (and the main code in application) are totally confused.

I am NOT saying it should NOT process the window events -- instead I am asking
    - do others see that problems can come from this?
    - how do others handle such seemingly asynchronous (but not really asynchronous) event handling??


-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              [hidden email]
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Steven Kelly
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Opening a Dialog window from a button processes windowevents???

Steven Kelly
Yes, it's a hole in VW event processing which has been there since 7.2.1. Whenever a dialog opens without an explicit parent window, VW sends defaultParentWindow, which eats all the events. It's a hack, and in my opinion a fairly nasty and dangerous one. There are other places too where VW breaks the ordering of events, and since these problems are in the low-level code of WindowManager et al., higher level code calls them probably without realising the dangers.
 
I'd much rather have a window get the wrong parent occasionally, than risk losing events and thus causing incorrect behaviour. Or in a RunTimePackaged image, having a simple error cause the whole app to summarily exit, rather than display an error dialog (displaying the error dialog calls #defaultParentWindow, which processes all events, causing the same error again -> RTP sees an infinite error recursion and quits the image).
 
You can see the recent conversations on this:
Cincomers can see EuroTSC Case 419933: AR 59917
 
I guess the reason why the #processAllOutstandingEvents hack was added was because of VW hanging if a dialog's parent window closed just as the dialog is opening:
I imagine there is a better solution to be found, without the nasty side effects.
 
Steve

 
From: [hidden email] on behalf of Dennis Smith
Sent: Thu 11/08/2011 21:18
To: VWNC,
Subject: [vwnc] Opening a Dialog window from a button processes windowevents???

It seems that when you open a Dialog from an existing non-modal window, that it runs all window events just before the dialog opens.

Consider this case
  1. button on a window which goes away and does things for 2 seconds (I did "Delay 2")
  2. have a requestForWindowClose method that puts up a dialog asking if the window should be closed
  3. press the button
  4. during those 2 seconds, press the [x] close button on the window, this queues an event for the window
So, after the 2 seconds expire, the button code opens a Dialog, but prior to that the window-events are processed and the requestForWindowClose code is invoked which puts up its own dialog -- at which point the button's dialog opens.

We now have two dialog boxes open and the user (and the main code in application) are totally confused.

I am NOT saying it should NOT process the window events -- instead I am asking
    - do others see that problems can come from this?
    - how do others handle such seemingly asynchronous (but not really asynchronous) event handling??


-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              [hidden email]
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Free forum by Nabble Edit this page