refreshing
Locked
12
12
 
|
Thanks for all the help with my multi-proc UI questions. I realize
now that all the windows were really under the same WindowManager all along. I had been looking at the wrong thing in the maze of objects from InputState through Sensors, Events, EventQueues, WindowManagers, ApplicationWindows, Builders and ApplicationModels. I think have a picture of how it all fits together now :-/ The problem we have been having is that events have been processed that we neither expected nor wanted to have processed. In particular, a <meta>+key sequence causes a dialog to open. If the sequence is repeated in quick succession, the first keyboard event starts to open the dialog, and then the second keyboard event gets to have a go at opening the same dialog, which causes a walkback. (We've told the users "well, don't do that", but you know how users are). I initially thought that the second event was getting through because of the changes between VW2.x and VW7.x and the multi-proc UI. It was a guess and a wrong one. Sorry about that. What seems to be happening is that in: ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: ... all the events for the WindowManager are explicitly processed - that's all the events for all the windows under the WindowManager. So, our first <meta>+key starts the dialog opening, and as a part of that all events get processes which causes the second <meta>+key to be handled too! What we want is to be able to is: o The parent window gets the <meta>+key event o The parent stops taking events o The dialog is opened & the user does their thing o The dialog closes o The patent resumes control and empties it's event queue (except for damage events, perhaps) o The parent starts accepting and all events again None of the sections in the manual (GUIDevGuide or AppDevGuide) seem to hit this spot on, so I'm asking for help again. Sorry to be a pest. All the best, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
My apologies for replying to my own post.
I have written up a description of my understanding of how UI events flow in VisualWorks. http://wiki.openskills.org/OpenSkills/VisualWorks+UI+Events This is the basis of my thinking about the problem I described in my previous post. I would be most grateful to anyone who could point out any holes or errors in this write up, as these would be hole or errors in my understanding :-/ Many thanks, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
In reply to this post by Bruce Badger
This sounds like the problem that was discussed a while back --
initiated by me. Below is the email thread -- if you can decode it bottom to top to see the original problem. I hope it makes sense I did not re-read it today, just appended it. ------------------------------------------------------------------- I have attached our changes as a fileIn. It is a rather simple change. Use a new ivar in the window manager that instructs it to ignore input events. It is up to the user's code to set and clear the ivar at the appropriate times. A couple of minor mods were also needed to some event classes. Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Steven Kelly [mailto:[hidden email]] > Sent: Friday, December 02, 2005 2:47 AM > To: VWNC, > Cc: Terry Raymond > Subject: RE: Interesting problem with actionButton ... > > Terry, > > It seems quite a few people have hit this problem of events during a > long operation. There are perhaps three main problems: > > 1) damage events are not processed until the long operation finishes > 2) input events during the long operation are queued and executed at the > end, possibly surprising the user > 3) a 2nd input event occurs before the 1st manages to open a window > > The bad news is that "long operation" here can be as short as 100ms. My > opinion is that the current WindowManager logic does not accurately > model what users expect. It seems to, providing operations are short, > but that's only because either no input events occur in that short > period, or then the delayed results (1 & 2 above) occur close enough to > the event that the user doesn't notice/mind. > > I have my own solution, RefreshingDisplayPolicy, which handles 1 & 2. > Here's the comment: > > "When a window's process is performing a long-running action, we want it > to be unresponsive to user input, but not to damage repair. During these > long-running actions, damage repair should be based on the visual state > immediately preceeding the current action, since models may be in an > unsuitable state for redisplay in the middle of the action. This visual > state is stored in the double-buffering pixmap. Windows with other > display policies are updated from their models during the long action. > > Call 'RefreshingDisplayPolicy usePixmapWhile: aBlock' for long > operations" > > The version in the public repository is a couple of years old. I later > added a progress window, and went as far as version 1.3.1 with it, but > in the end could not make it 100% reliable in cases where long > operations wanted to open dialogs, which then SHOULD receive input. For > version 2.0 I replaced the progress window with a progress dialog. This > also stops users from resizing or closing other windows, keeps the > progress dialog on top, and flashes it if users try to work in other > windows. > > I'd be really interested in seeing your solution, in particular if it > cures what I see as design flaws in WindowManager event processing. > > Cheers, > Steve > > > -----Original Message----- > > From: Terry Raymond [mailto:[hidden email]] > > Sent: 01 December 2005 03:59 > > To: 'Dennis Smith'; 'VWNC, ' > > Subject: RE: Interesting problem with actionButton ... > > > > > > Dennis > > > > Our system is a client/server system. At times it is > > possible for a client request to take a while. However, > > we also want the various active applications to update > > their displays with current data coming from the server > > while the user is waiting for his response. This meant > > we could not block the UI process while it waited for a response. > > > > My solution was to modify the window manager and a couple > > of event classes so it would ignore any user input events > > until the server completed the user's request. > > > > It works quite well. > > > > Terry > > > > =========================================================== > > Terry Raymond Smalltalk Professional Debug Package > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > <http://www.craftedsmalltalk.com> > > =========================================================== > > > > -----Original Message----- > > > > From: Dennis Smith [mailto:[hidden email]] > > > > Sent: Wednesday, November 30, 2005 1:29 PM > > > > To: VWNC, > > > > Subject: Interesting problem with actionButton ... > > > > > > > > I am wondering if anyone else has encountered this problem > > > and/or has > > > > a solution better than mine? > > > > > > > > We have an application window with fields and buttons. > > > > One of the buttons after a short time (depending on > > > > database accesses) may open a modal window. > > > > > > > > So the user presses this button -- then seeing nothing > > > > after a second, presses it again. Both presses are > > > > dealt with and two modal windows open. The user > > > > completes each creating TWO business objects where there should be > > > > ONE. > > > > > > > > Here is what I am trying as a solution: > > > > > > > > I created a method "actionFor: .." to handle all button > > > presses in my > > > > business applications. > > > > > > > > In that method I do this > > > > > > > > ... > > > > [[self builder window controller flushMetaInput] > > > uiEventFor: self > > > > builder window] fork > > > > ... do normal button handling ... > > > > > > > > The theory is that this will queue as the next event an event which > > > > will flush any other events from the window. This will be run only > > > > when the windowManager gets to process > > > > events and at that point the modal window will be open -- > > > so any extra > > > > presses of the button > > > > will be discarded. > > > > > > > > The "fork" is required to prevent the method from being run > > > > immediately since the current process IS the window process. > > > > > > > > This seems to work. > > > > > > > > > > > > -- > > > > Dennis Smith [hidden email] > > > > Cherniak Software Development Corporation +1 905.771.7011 > > > > 400-10 Commerce Valley Dr E Fax: +1 905.771.6288 > > > > Thornhill, ON Canada L3T 7N7 http://www.CherniakSoftware.com > ---------------------------------------------------------------------- Bruce Badger wrote: > Thanks for all the help with my multi-proc UI questions. I realize > now that all the windows were really under the same WindowManager all > along. I had been looking at the wrong thing in the maze of objects > from InputState through Sensors, Events, EventQueues, WindowManagers, > ApplicationWindows, Builders and ApplicationModels. I think have a > picture of how it all fits together now :-/ > > The problem we have been having is that events have been processed > that we neither expected nor wanted to have processed. In particular, > a <meta>+key sequence causes a dialog to open. If the sequence is > repeated in quick succession, the first keyboard event starts to open > the dialog, and then the second keyboard event gets to have a go at > opening the same dialog, which causes a walkback. (We've told the > users "well, don't do that", but you know how users are). > > I initially thought that the second event was getting through because > of the changes between VW2.x and VW7.x and the multi-proc UI. It was > a guess and a wrong one. Sorry about that. > > What seems to be happening is that in: > > ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: > > ... all the events for the WindowManager are explicitly processed - > that's all the events for all the windows under the WindowManager. > So, our first <meta>+key starts the dialog opening, and as a part of > that all events get processes which causes the second <meta>+key to be > handled too! > > What we want is to be able to is: > > o The parent window gets the <meta>+key event > o The parent stops taking events > o The dialog is opened & the user does their thing > o The dialog closes > o The patent resumes control and empties it's event queue (except for > damage events, perhaps) > o The parent starts accepting and all events again > > None of the sections in the manual (GUIDevGuide or AppDevGuide) seem > to hit this spot on, so I'm asking for help again. > > Sorry to be a pest. > > All the best, > Bruce > -- > Make the most of your skills - with OpenSkills > http://www.openskills.org/ > > -- Dennis Smith [hidden email] Cherniak Software Development Corporation +1 905.771.7011 400-10 Commerce Valley Dr E Fax: +1 905.771.6288 Thornhill, ON Canada L3T 7N7 http://www.CherniakSoftware.com |
|
|
In reply to this post by Bruce Badger
Bruce
It would seem to me that the simplest solution would be for the parent application to set a flag when it gets the first request, and before it opens the dialog. Until the flag gets reset the parent would ignore any keyboard or mouse button requests. I don't think you can do this at the WindowManager level because you still want to process input events for the dialog. Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Bruce Badger [mailto:[hidden email]] > Sent: Tuesday, February 14, 2006 4:36 AM > To: Vwnc > Subject: refreshing > > Thanks for all the help with my multi-proc UI questions. I realize > now that all the windows were really under the same WindowManager all > along. I had been looking at the wrong thing in the maze of objects > from InputState through Sensors, Events, EventQueues, WindowManagers, > ApplicationWindows, Builders and ApplicationModels. I think have a > picture of how it all fits together now :-/ > > The problem we have been having is that events have been processed > that we neither expected nor wanted to have processed. In particular, > a <meta>+key sequence causes a dialog to open. If the sequence is > repeated in quick succession, the first keyboard event starts to open > the dialog, and then the second keyboard event gets to have a go at > opening the same dialog, which causes a walkback. (We've told the > users "well, don't do that", but you know how users are). > > I initially thought that the second event was getting through because > of the changes between VW2.x and VW7.x and the multi-proc UI. It was > a guess and a wrong one. Sorry about that. > > What seems to be happening is that in: > > ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: > > ... all the events for the WindowManager are explicitly processed - > that's all the events for all the windows under the WindowManager. > So, our first <meta>+key starts the dialog opening, and as a part of > that all events get processes which causes the second <meta>+key to be > handled too! > > What we want is to be able to is: > > o The parent window gets the <meta>+key event > o The parent stops taking events > o The dialog is opened & the user does their thing > o The dialog closes > o The patent resumes control and empties it's event queue (except for > damage events, perhaps) > o The parent starts accepting and all events again > > None of the sections in the manual (GUIDevGuide or AppDevGuide) seem > to hit this spot on, so I'm asking for help again. > > Sorry to be a pest. > > All the best, > Bruce > -- > Make the most of your skills - with OpenSkills > http://www.openskills.org/ |
|
|
In reply to this post by Bruce Badger
Terry,
That's one of the things a modal dialog is supposed to do: block all input events for the application that opened it. A quick search on Google ("modal dialog" input) confirms this for many different platforms and UI frameworks, e.g. for Windows: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/w inui/windowsuserinterface/windowing/dialogboxes/aboutdialogboxes.asp "When the owner window is not already disabled, the system automatically disables the window and any child windows belonging to it when it creates the modal dialog box. The owner window remains disabled until the dialog box is destroyed" I believe this is the correct and expected behaviour, and I hope to see VW corrected to work this way. As VW programmers we shouldn't have to insert a flag set in every single command that opens a dialog, and a flag check in every single other command (many of which would be at a far lower level than our application code, e.g. ignoring clicks on the up button of a spin box). Cheers, Steve > -----Original Message----- > From: Terry Raymond [mailto:[hidden email]] > Sent: 14 February 2006 16:32 > To: 'Bruce Badger'; 'Vwnc' > Subject: RE: refreshing > > > Bruce > > It would seem to me that the simplest solution would be > for the parent application to set a flag when it gets the > first request, and before it opens the dialog. Until the > flag gets reset the parent would ignore any keyboard or > mouse button requests. > > I don't think you can do this at the WindowManager level > because you still want to process input events for the dialog. > > Terry > > =========================================================== > Terry Raymond Smalltalk Professional Debug Package > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > -----Original Message----- > > From: Bruce Badger [mailto:[hidden email]] > > Sent: Tuesday, February 14, 2006 4:36 AM > > To: Vwnc > > Subject: refreshing > > > > Thanks for all the help with my multi-proc UI questions. I realize > > now that all the windows were really under the same > WindowManager all > > along. I had been looking at the wrong thing in the maze > of objects > > from InputState through Sensors, Events, EventQueues, > WindowManagers, > > ApplicationWindows, Builders and ApplicationModels. I think have a > > picture of how it all fits together now :-/ > > > > The problem we have been having is that events have been processed > > that we neither expected nor wanted to have processed. In > particular, > > a <meta>+key sequence causes a dialog to open. If the sequence is > > repeated in quick succession, the first keyboard event > starts to open > > the dialog, and then the second keyboard event gets to have a go at > > opening the same dialog, which causes a walkback. (We've told the > > users "well, don't do that", but you know how users are). > > > > I initially thought that the second event was getting > through because > > of the changes between VW2.x and VW7.x and the multi-proc > UI. It was > > a guess and a wrong one. Sorry about that. > > > > What seems to be happening is that in: > > > > ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: > > > > ... all the events for the WindowManager are explicitly processed - > > that's all the events for all the windows under the > WindowManager. So, > > our first <meta>+key starts the dialog opening, and as a > part of that > > all events get processes which causes the second <meta>+key to be > > handled too! > > > > What we want is to be able to is: > > > > o The parent window gets the <meta>+key event > > o The parent stops taking events > > o The dialog is opened & the user does their thing > > o The dialog closes > > o The patent resumes control and empties it's event queue > (except for > > damage events, perhaps) o The parent starts accepting and > all events > > again > > > > None of the sections in the manual (GUIDevGuide or > AppDevGuide) seem > > to hit this spot on, so I'm asking for help again. > > > > Sorry to be a pest. > > > > All the best, > > Bruce > > -- > > Make the most of your skills - with OpenSkills > > http://www.openskills.org/ > > |
|
|
In reply to this post by Terry Raymond
Terry,
On 15/02/06, Terry Raymond <[hidden email]> wrote: > It would seem to me that the simplest solution would be > for the parent application to set a flag when it gets the > first request, and before it opens the dialog. Until the > flag gets reset the parent would ignore any keyboard or > mouse button requests. So, what is the current best practice when it comes to having a particular ApplicationWindow within a WindowManager ignore keyboard & mouse input, and then resume accepting it later? An RTFM would fine if you could point me to the right bit of the FM. :-) > I don't think you can do this at the WindowManager level > because you still want to process input events for the > dialog. Right, I understand now. I think. Many thanks, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
In reply to this post by Steven Kelly
Steve
You are correct. Maybe there is a bug in ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Steven Kelly [mailto:[hidden email]] > Sent: Tuesday, February 14, 2006 10:32 AM > To: Terry Raymond; Bruce Badger; Vwnc > Subject: RE: refreshing > > Terry, > > That's one of the things a modal dialog is supposed to do: block all > input events for the application that opened it. A quick search on > Google ("modal dialog" input) confirms this for many different platforms > and UI frameworks, e.g. for Windows: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/w > inui/windowsuserinterface/windowing/dialogboxes/aboutdialogboxes.asp > "When the owner window is not already disabled, the system automatically > disables the window and any child windows belonging to it when it > creates the modal dialog box. The owner window remains disabled until > the dialog box is destroyed" > > I believe this is the correct and expected behaviour, and I hope to see > VW corrected to work this way. As VW programmers we shouldn't have to > insert a flag set in every single command that opens a dialog, and a > flag check in every single other command (many of which would be at a > far lower level than our application code, e.g. ignoring clicks on the > up button of a spin box). > > Cheers, > Steve > > > -----Original Message----- > > From: Terry Raymond [mailto:[hidden email]] > > Sent: 14 February 2006 16:32 > > To: 'Bruce Badger'; 'Vwnc' > > Subject: RE: refreshing > > > > > > Bruce > > > > It would seem to me that the simplest solution would be > > for the parent application to set a flag when it gets the > > first request, and before it opens the dialog. Until the > > flag gets reset the parent would ignore any keyboard or > > mouse button requests. > > > > I don't think you can do this at the WindowManager level > > because you still want to process input events for the dialog. > > > > Terry > > > > =========================================================== > > Terry Raymond Smalltalk Professional Debug Package > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > <http://www.craftedsmalltalk.com> > > =========================================================== > > > -----Original Message----- > > > From: Bruce Badger [mailto:[hidden email]] > > > Sent: Tuesday, February 14, 2006 4:36 AM > > > To: Vwnc > > > Subject: refreshing > > > > > > Thanks for all the help with my multi-proc UI questions. I realize > > > now that all the windows were really under the same > > WindowManager all > > > along. I had been looking at the wrong thing in the maze > > of objects > > > from InputState through Sensors, Events, EventQueues, > > WindowManagers, > > > ApplicationWindows, Builders and ApplicationModels. I think have a > > > picture of how it all fits together now :-/ > > > > > > The problem we have been having is that events have been processed > > > that we neither expected nor wanted to have processed. In > > particular, > > > a <meta>+key sequence causes a dialog to open. If the sequence is > > > repeated in quick succession, the first keyboard event > > starts to open > > > the dialog, and then the second keyboard event gets to have a go at > > > opening the same dialog, which causes a walkback. (We've told the > > > users "well, don't do that", but you know how users are). > > > > > > I initially thought that the second event was getting > > through because > > > of the changes between VW2.x and VW7.x and the multi-proc > > UI. It was > > > a guess and a wrong one. Sorry about that. > > > > > > What seems to be happening is that in: > > > > > > ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: > > > > > > ... all the events for the WindowManager are explicitly processed - > > > that's all the events for all the windows under the > > WindowManager. So, > > > our first <meta>+key starts the dialog opening, and as a > > part of that > > > all events get processes which causes the second <meta>+key to be > > > handled too! > > > > > > What we want is to be able to is: > > > > > > o The parent window gets the <meta>+key event > > > o The parent stops taking events > > > o The dialog is opened & the user does their thing > > > o The dialog closes > > > o The patent resumes control and empties it's event queue > > (except for > > > damage events, perhaps) o The parent starts accepting and > > all events > > > again > > > > > > None of the sections in the manual (GUIDevGuide or > > AppDevGuide) seem > > > to hit this spot on, so I'm asking for help again. > > > > > > Sorry to be a pest. > > > > > > All the best, > > > Bruce > > > -- > > > Make the most of your skills - with OpenSkills > > > http://www.openskills.org/ > > > > |
|
|
At least on Windows the EnableWindow(true/false) API-Call which suppresses input to the calling window is done at the VM level, which also tracks the Z-Order of windows. I think you cannot deal with it explicitely at the image level. (At least not until the gui code is torn out of the VM in -- what was the code name for it after Pollock, peaches, ...?) Thomas > -----Original Message----- > From: Terry Raymond [mailto:[hidden email]] > Sent: Tuesday, February 14, 2006 7:04 PM > To: 'Steven Kelly'; 'Bruce Badger'; 'Vwnc' > Subject: RE: refreshing > > Steve > > You are correct. Maybe there is a bug in > ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: > > Terry > > =========================================================== > Terry Raymond Smalltalk Professional Debug Package > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > > -----Original Message----- > > From: Steven Kelly [mailto:[hidden email]] > > Sent: Tuesday, February 14, 2006 10:32 AM > > To: Terry Raymond; Bruce Badger; Vwnc > > Subject: RE: refreshing > > > > Terry, > > > > That's one of the things a modal dialog is supposed to do: block all > > input events for the application that opened it. A quick search on > > Google ("modal dialog" input) confirms this for many > different platforms > > and UI frameworks, e.g. for Windows: > > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/winui/w > > inui/windowsuserinterface/windowing/dialogboxes/aboutdialogboxes.asp > > "When the owner window is not already disabled, the system > automatically > > disables the window and any child windows belonging to it when it > > creates the modal dialog box. The owner window remains > disabled until > > the dialog box is destroyed" > > > > I believe this is the correct and expected behaviour, and I > hope to see > > VW corrected to work this way. As VW programmers we > shouldn't have to > > insert a flag set in every single command that opens a dialog, and a > > flag check in every single other command (many of which > would be at a > > far lower level than our application code, e.g. ignoring > clicks on the > > up button of a spin box). > > > > Cheers, > > Steve > > > > > -----Original Message----- > > > From: Terry Raymond [mailto:[hidden email]] > > > Sent: 14 February 2006 16:32 > > > To: 'Bruce Badger'; 'Vwnc' > > > Subject: RE: refreshing > > > > > > > > > Bruce > > > > > > It would seem to me that the simplest solution would be > > > for the parent application to set a flag when it gets the > > > first request, and before it opens the dialog. Until the > > > flag gets reset the parent would ignore any keyboard or > > > mouse button requests. > > > > > > I don't think you can do this at the WindowManager level > > > because you still want to process input events for the dialog. > > > > > > Terry > > > > > > =========================================================== > > > Terry Raymond Smalltalk Professional Debug Package > > > Crafted Smalltalk > > > 80 Lazywood Ln. > > > Tiverton, RI 02878 > > > (401) 624-4517 [hidden email] > > > <http://www.craftedsmalltalk.com> > > > =========================================================== > > > > -----Original Message----- > > > > From: Bruce Badger [mailto:[hidden email]] > > > > Sent: Tuesday, February 14, 2006 4:36 AM > > > > To: Vwnc > > > > Subject: refreshing > > > > > > > > Thanks for all the help with my multi-proc UI > questions. I realize > > > > now that all the windows were really under the same > > > WindowManager all > > > > along. I had been looking at the wrong thing in the maze > > > of objects > > > > from InputState through Sensors, Events, EventQueues, > > > WindowManagers, > > > > ApplicationWindows, Builders and ApplicationModels. I > think have a > > > > picture of how it all fits together now :-/ > > > > > > > > The problem we have been having is that events have > been processed > > > > that we neither expected nor wanted to have processed. In > > > particular, > > > > a <meta>+key sequence causes a dialog to open. If the > sequence is > > > > repeated in quick succession, the first keyboard event > > > starts to open > > > > the dialog, and then the second keyboard event gets to > have a go at > > > > opening the same dialog, which causes a walkback. > (We've told the > > > > users "well, don't do that", but you know how users are). > > > > > > > > I initially thought that the second event was getting > > > through because > > > > of the changes between VW2.x and VW7.x and the multi-proc > > > UI. It was > > > > a guess and a wrong one. Sorry about that. > > > > > > > > What seems to be happening is that in: > > > > > > > > ApplicationWindow > (ScheduledWindow)>>openTransientIn:type:postOpen: > > > > > > > > ... all the events for the WindowManager are explicitly > processed - > > > > that's all the events for all the windows under the > > > WindowManager. So, > > > > our first <meta>+key starts the dialog opening, and as a > > > part of that > > > > all events get processes which causes the second > <meta>+key to be > > > > handled too! > > > > > > > > What we want is to be able to is: > > > > > > > > o The parent window gets the <meta>+key event > > > > o The parent stops taking events > > > > o The dialog is opened & the user does their thing > > > > o The dialog closes > > > > o The patent resumes control and empties it's event queue > > > (except for > > > > damage events, perhaps) o The parent starts accepting and > > > all events > > > > again > > > > > > > > None of the sections in the manual (GUIDevGuide or > > > AppDevGuide) seem > > > > to hit this spot on, so I'm asking for help again. > > > > > > > > Sorry to be a pest. > > > > > > > > All the best, > > > > Bruce > > > > -- > > > > Make the most of your skills - with OpenSkills > > > > http://www.openskills.org/ > > > > > > > > |
|
|
In reply to this post by Bruce Badger
Terry,
On 15/02/06, Terry Raymond <[hidden email]> wrote: > I have not encountered your problem before. It sounds to > like your postOpen processing is slow so the user has > time to generate another event before the dialog takes > control. I'm hopeful that we won't have to endure a timing issue in a nice green threaded environment like VisualWorks. I think there is indeed a problem in: ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: Does anyone know why in that method we see the following? self windowManager processOutstandingEvents. So, here we are in the middle of opening a modal dialog, and we ask the WindowManager to process all outstanding events for all the windows within it. I would have thought that's the last thing we want (except perhaps for damage events). The next question might be: but why are there any events in the queue anyway? As Steve Kelly points out, the first thing to happen when opening a dialog should be to suspend events for the parent. And then, as has also been pointed out, any events for the parent that do get into the queue should be dropped (except perhaps damage) once the dialog closes. I'm having a look at the work done by Dennis and Steve to see how to fix things here. I'll report back when I have something working. Really though this is a honest to goodness bug in VisualWorks that a number of people have had to work around, and which has no doubt caused many frowns from people who hit the bug only rarely and can't reproduce it. I urge Cincom to assign someone to help getting it fixed. For everyone. Best regards, Bruce |
|
|
Bruce Badger wrote:
> > I'm hopeful that we won't have to endure a timing issue in a nice > green threaded environment like VisualWorks. > Dream on, here are some more threading issues: -- Note the presence of #ifNotNil: hacks in WindowManager class>>managerRegistryDo:, I cannot explain these otherwise than them being the proverbial paper over threading bugs, removing them will freeze your image... -- When a UI thread spawns a new window with a new manager there is a stretch of time where both the spawning and the spawned WM's process are handling events in the spawned WM's queue. This normally doesn't lead to problems because both are running at the same priority so the spawning thread will complete before the spawned thread gets CPU. Problems do arise when the spawned window has a #postOpenWith: or #postBuildWith: that can block (e.g. reading records from a DB). One way this bug expresses itself is that a user can press buttons (and have them processed) on the spawned window *before* it's #postBuild/Open has completed running. -- FlybyHelp is suspect (I'm not sure it is broken) because it has bouts where it will spawn several WM's per second (without crashing or such). -- NullWindowManager doesNotUnderstand: #windowProcess We see this in development as well as deployed images. Don't know any way around it, it is a gaping hole in the multiproc model that nobody has tackled yet. > I urge Cincom to assign someone to help getting it fixed. For everyone. pretty please... Reinout ------- -- Reinout Heeck ------------- Idle curiosity is the enemy of a quiet life. |
|
|
On Feb 15, 2006, at 1:28, Reinout Heeck wrote: > Bruce Badger wrote: >> I'm hopeful that we won't have to endure a timing issue in a nice >> green threaded environment like VisualWorks. > > Dream on, here are some more threading issues: > > -- Note the presence of #ifNotNil: hacks in WindowManager > class>>managerRegistryDo:, I cannot explain these otherwise than them > being the proverbial paper over threading bugs, removing them will > freeze your image... > > -- When a UI thread spawns a new window with a new manager there is a > stretch of time where both the spawning and the spawned WM's > process are > handling events in the spawned WM's queue. This normally doesn't > lead to > problems because both are running at the same priority so the spawning > thread will complete before the spawned thread gets CPU. > Problems do arise when the spawned window has a #postOpenWith: or > #postBuildWith: that can block (e.g. reading records from a DB). > One way > this bug expresses itself is that a user can press buttons (and have > them processed) on the spawned window *before* it's #postBuild/Open > has > completed running. > > > -- FlybyHelp is suspect (I'm not sure it is broken) because it has > bouts > where it will spawn several WM's per second (without crashing or > such). > > > -- NullWindowManager doesNotUnderstand: #windowProcess > We see this in development as well as deployed images. Don't know any > way around it, it is a gaping hole in the multiproc model that nobody > has tackled yet. > > >> I urge Cincom to assign someone to help getting it fixed. For >> everyone. > > pretty please... <obligatory> It'll all be fixed in Pollock </obligatory> -- Travis Griggs Objologist "Conference calls: the appearance of doing work without the substance thereof" - Bruce Boyer ----------------------------------------- DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm |
Re: refreshing
|
|
In reply to this post by Bruce Badger
Bruce,
>I think there is indeed a problem in: > > ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: > >Does anyone know why in that method we see the following? > > self windowManager processOutstandingEvents. > >So, here we are in the middle of opening a modal dialog, and we ask >the WindowManager to process all outstanding events for all the >windows within it. I would have thought that's the last thing we want >(except perhaps for damage events). What events do you think are being processed? The target window is already open by the time this message is sent. Of course, in Wrapper, the controller hasn't taken control (that happens next). Except if the user gets fast before mouse grabs are set up, well, everything goes well. All that said, you can try taking that out, or even replace it with drainOutstandingEvents, but then you may lose events going to the dialog... because... what window manager do you think that dialog is using? Unless otherwise stipulated, it uses the same one as the launching window. Now, how can the user get in fast enough to get a second click on the launching window? Well, there is a finite amount of time before the controller takes over. And the window has to be built and mouse grabbed. Fortunately, in Pollock, MUCH less time is spent between launching and the grab. But there will always be some until we go to native widgets and the event loop in the image. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Smalltalk Enables Success -- What Are YOU Using? |
|
|
Sam,
On 16/02/06, Samuel S. Shuster <[hidden email]> wrote: > > ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: > > self windowManager processOutstandingEvents. > > > >So, here we are in the middle of opening a modal dialog, and we ask > >the WindowManager to process all outstanding events for all the > >windows within it. I would have thought that's the last thing we want > >(except perhaps for damage events). > > What events do you think are being processed? The target window is already open > by the time this message is sent. Of course, in Wrapper, the controller hasn't > taken control (that happens next). Except if the user gets fast before mouse > grabs are set up, well, everything goes well. I guess my answer has to be: I don't know what events might be in the queue. The return question is: what is the benefit of processing all events for all windows in a WindowManager? After all, at this point in the code we don't know what those events are or what the side effects could be - it's like Russian Roulette. In the case of our app, the events that got processed were ones input by the user against the parent window during a time window created by the application doing IO after receiving the request to open the dialog (and <alt>+key sequence) and the dialog class being asked to open. My rather ugly fix lets the programmer of the ApplicationModel close that time window by being able to explicitly say "accept no more events (except damage) while I futz around getting this dialog started". The bad thing is (and the thing that makes this a bug IMO) is that there is no way to do this without making changes to base classes AFAIKT. > All that said, you can try taking that out, or even replace it with > drainOutstandingEvents, but then you may lose events going to the dialog... > because... what window manager do you think that dialog is using? Unless > otherwise stipulated, it uses the same one as the launching window. Yes, the WindowManager is the same for the dialog and the parent. But of course there could be other windows in there too, and in our case *all* the application windows are in the one WindowManager (it's an old app not designed for multi-proc). I would not feel very comfortable replacing a line of code that I can see not point in having with another that I don't understand the effect of. That would seem to be programming by hunch or even guess (or even blind hope in my case). Scary. > Now, how can the user get in fast enough to get a second click on the launching > window? Well, there is a finite amount of time before the controller takes over. > And the window has to be built and mouse grabbed. It turns out to be very easy. In the ApplicationModel method that gets the event requesting the dialog to open, just do heaps of IO (e.g. database access) before actually opening the dialog window. This give the user plenty of time to whack the keyboard and wobble the mouse all over the place, potentially generating events for any number of other windows in the same WindowManager. > Fortunately, in Pollock, MUCH less time is spent between launching and the grab. > But there will always be some until we go to native widgets and the event loop > in the image. This is good, but the ApplicationModel programmer still needs a way to say: "Ah, thanks for that event requesting a dialog. Hey, WindowManager, don't take any more events for me while I get my act together and open this here dialog." That's what my fix tries to do, and what I think needs to be provided in some form in the base classes. Comments on my kludge of a fix would be greatly appreciated. Thanks, Sam. All the best, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
Bruce
Because of the timing involved it seems to me you either have to be able to set some state that directs an app window to discard all input events, or redirect the input events to the dialog. If your long processing occurs in the post open then I think you might be able to use the input state grab queue to redirect the input events to the dialog. You could try setting the grab queue up before doing the processing on the post open. Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Bruce Badger [mailto:[hidden email]] > Sent: Wednesday, February 15, 2006 3:18 PM > To: Vwnc > Subject: Re: refreshing > > Sam, > > On 16/02/06, Samuel S. Shuster <[hidden email]> wrote: > > > ApplicationWindow (ScheduledWindow)>>openTransientIn:type:postOpen: > > > self windowManager processOutstandingEvents. > > > > > >So, here we are in the middle of opening a modal dialog, and we ask > > >the WindowManager to process all outstanding events for all the > > >windows within it. I would have thought that's the last thing we want > > >(except perhaps for damage events). > > > > What events do you think are being processed? The target window is > already open > > by the time this message is sent. Of course, in Wrapper, the controller > hasn't > > taken control (that happens next). Except if the user gets fast before > mouse > > grabs are set up, well, everything goes well. > > I guess my answer has to be: I don't know what events might be in the > queue. The return question is: what is the benefit of processing all > events for all windows in a WindowManager? After all, at this point > in the code we don't know what those events are or what the side > effects could be - it's like Russian Roulette. > > In the case of our app, the events that got processed were ones input > by the user against the parent window during a time window created by > the application doing IO after receiving the request to open the > dialog (and <alt>+key sequence) and the dialog class being asked to > open. > > My rather ugly fix lets the programmer of the ApplicationModel close > that time window by being able to explicitly say "accept no more > events (except damage) while I futz around getting this dialog > started". The bad thing is (and the thing that makes this a bug IMO) > is that there is no way to do this without making changes to base > classes AFAIKT. > > > All that said, you can try taking that out, or even replace it with > > drainOutstandingEvents, but then you may lose events going to the > dialog... > > because... what window manager do you think that dialog is using? Unless > > otherwise stipulated, it uses the same one as the launching window. > > Yes, the WindowManager is the same for the dialog and the parent. But > of course there could be other windows in there too, and in our case > *all* the application windows are in the one WindowManager (it's an > old app not designed for multi-proc). > > I would not feel very comfortable replacing a line of code that I can > see not point in having with another that I don't understand the > effect of. That would seem to be programming by hunch or even guess > (or even blind hope in my case). Scary. > > > Now, how can the user get in fast enough to get a second click on the > launching > > window? Well, there is a finite amount of time before the controller > takes over. > > And the window has to be built and mouse grabbed. > > It turns out to be very easy. In the ApplicationModel method that > gets the event requesting the dialog to open, just do heaps of IO > (e.g. database access) before actually opening the dialog window. > This give the user plenty of time to whack the keyboard and wobble the > mouse all over the place, potentially generating events for any number > of other windows in the same WindowManager. > > > Fortunately, in Pollock, MUCH less time is spent between launching and > the grab. > > But there will always be some until we go to native widgets and the > event loop > > in the image. > > This is good, but the ApplicationModel programmer still needs a way to > say: "Ah, thanks for that event requesting a dialog. Hey, > WindowManager, don't take any more events for me while I get my act > together and open this here dialog." > > That's what my fix tries to do, and what I think needs to be provided > in some form in the base classes. > > Comments on my kludge of a fix would be greatly appreciated. > > Thanks, Sam. > > All the best, > Bruce > -- > Make the most of your skills - with OpenSkills > http://www.openskills.org/ |
|
|
Terry,
On 16/02/06, Terry Raymond <[hidden email]> wrote: > Because of the timing involved it seems to me you either > have to be able to set some state that directs an app window > to discard all input events, or redirect the input events > to the dialog. I have a solution that seems to work. I described it in a separate thread. I asked for comments on it too, and yours would be most welcome :-) In fact, the solution uses a block to establish a context within which events are not queued for a given window (the parent of the dialog in my case). This seemed neater to me than using flags to represent the state, but I may be missing something important due to my lack of VW GUI experience. The problem is that to make it work I had to change base classes, and this is bad IMO. I ought to be able to solve this using the behavior that ships with VisualWorks, but I could not see how to do that. > If your long processing occurs in the post open ... In our case, the delay does not happen in the post open. The long process happens in the method that is invoked as a result of an accelerator key event. As it happens it was <alt>+s. If the user hit <alt>+s twice in quick succession, the first event starts a method to open a dialog and while that method did some IO, the second event got into the queue. As part of opening the dialog, all events in the queue of the WindowManager are processed including the second <alt>+s. Handling the second <alt>+s causes the ApplicationModel (which at this point is in the middle of opening the dialog in response to the *first* <alt>+s, of course) to fail. > ...you might be able to use the input state grab queue to > redirect the input events to the dialog. You could try > setting the grab queue up before doing the processing > on the post open. Yes, this is essentially what my kludge does. I've added >>addEvent: to ApplicationWindow (overriding the implementation in Window) which uses a filter block. The default filter block does the same as the behavior of >>addEvent in Window, i.e. all events go to the queue. The alternate blocks either drop all events, or all except damage events. So, the flow of events into the WindowManager EventQueue for a particular ApplicationWindow can be switched on and off by just flipping these blocks around. I also added a helper methods to ApplicationWindow: >>doWhileHandlingOnlyDamageEvents: aBlock >>doWhileIgnoringAllEvents: aBlock These two remember the current filter block, install thier own filter block, evaluate the block given as an argument, and lastly put the original filter block back in place. This means that in the method which handles the <alt>+s event, I simply have: self mainWindow doWhileHandlingOnlyDamageEvents: [ |modelObject| modelObject := self doLotsOfSlowIOToGetModelObject. (MyDialogWindow for: modelObject) openAsDialog] In this way, the fix suspends events being added to the queue for the parent window immediately. Thus the second <alt>+s (as described above) is ignored even if it gets picked up by the InputState. A normal service is resumed without me having to write explicit code in my ApplicationModel. So, to summarize: o I have a solution, but would appreciate comments on it. Is it sane? o I think that being compelled to modify the base classes counts as a bug. All the best, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
On 16/02/06, Bruce Badger <[hidden email]> wrote:
> I also added a helper methods to ApplicationWindow: > >>doWhileHandlingOnlyDamageEvents: aBlock > >>doWhileIgnoringAllEvents: aBlock > > These two remember the current filter block, install thier own filter > block, evaluate the block given as an argument, and lastly put the > original filter block back in place. It strikes me that these two methods should remove any events already in the WindowManager EventQueue for the subject ApplicationWindow after the filter block is in place and before the block given as an argument is evaluated. It looks like >>drainOutstandingEventsFor: aWindow should work, so I'll go with that. -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
In reply to this post by Bruce Badger
From: Bruce Badger [mailto:[hidden email]]
> I have a solution that seems to work. I described it in a > separate thread. I asked for comments on it too, and yours > would be most welcome :-) And here we have a problem: there are at least 4 solutions of this issue that I've seen now, and each time my guess is that although people make them public, nobody else is willing to look at them. I know I'm reluctant to look in detail at Bruce's, and the reason is that I know the code is going to be a hack to repair things that are broken in VW. Trying to understand someone else's code, at the same time as trying to understand how VW is broken, is very hard. Making my own code took a week or two in total, because I had to keep going back to it again and again as new weird cases appeared because of new VW issues being revealed. Any mistake in code like this tends to lead to serious problems, e.g. VW completely refusing to accept input to any window, which customers obviously won't accept, even if it's rare. The current VW code tends to work the other way, leaking events that it is trying to stop - e.g. you can work in a browser while performing a long Store operation, because the Transcript in the Store progress window leaks events to other windows when updating its text (TextControllerView>>update: sends "self topComponent windowManager processOutstandingEvents"). Until someone sorts out VW, we're essentially trying to dam the sea. > Yes, this is essentially what my kludge does. I've added > >>addEvent: to ApplicationWindow (overriding the > implementation in Window) which uses a filter block. The > default filter block does the same as the behavior of > >>addEvent in Window, i.e. all events go to the queue. > The alternate blocks either drop all events, or all except > damage events. That's essentially what I did in my change to addEvent: in WindowManager, and it works for me. I'm not sure whether I like it more in WindowManager or ApplicationWindow - probably the former, since that's where I perceive the bad behaviour to be. Having it there also let me have a shared var, DisabledWindows, in WindowManager, rather than an inst var in ApplicationWindow. When making changes to the base, I feel the riskiest change is an iv, then a method override, then an extension method, then an addition of a shared var. I define the windows that shouldn't get input events as those that are open at the start of the long block. If the block itself opens dialogs, they should get events; if it opens windows (non-modal), we might want them to get input events. > It strikes me that these two methods should remove any events > already in the WindowManager EventQueue for the subject > ApplicationWindow after the filter block is in place and > before the block given as an argument is evaluated. > > It looks like >>drainOutstandingEventsFor: aWindow should > work, so I'll go with that. Offhand, I'd say it's wrong. You only want to drain input events, not damage events, otherwise you can miss areas that need repainting. You need something like I did, to process all damage events for all windows while leaving the rest there. That handles the repaint. After that you can decide whether you want to drain input events for this window / all windows, or leave them to be processed after the long block. You'll also need to think about close events etc., which might be triggered programmatically. HTH, and good luck! Steve |
|
|
Steve,
On 16/02/06, Steven Kelly <[hidden email]> wrote: > From: Bruce Badger [mailto:[hidden email]] > > I have a solution that seems to work. I described it in a > > separate thread. I asked for comments on it too, and yours > > would be most welcome :-) > > And here we have a problem: there are at least 4 solutions of this issue > that I've seen now... Making my own code took a > week or two in total, because I had to keep going back to it again and > again as new weird cases appeared because of new VW issues being > revealed. Well, I was able to get things going in just a few days because I had some examples to look at, so I'd like to thank those who went before me. > Any mistake in code like this tends to lead to serious problems ... > ... Until someone > sorts out VW, we're essentially trying to dam the sea. Absolutely agreed. > > ... I've added > > >>addEvent: to ApplicationWindow (overriding the > > implementation in Window) which uses a filter block. > That's essentially what I did in my change to addEvent: in > WindowManager, and it works for me. I'm not sure whether I like it more > in WindowManager or ApplicationWindow - probably the former, since > that's where I perceive the bad behaviour to be. Having it there also > let me have a shared var, DisabledWindows, in WindowManager, rather than > an inst var in ApplicationWindow. The problems we were having tended to be associated with the transition between one window and another (e.g. a window opening a dialog), and then only where time consuming work happened between getting the event that called for the transition and actually opening the dialog. In this case is seems to work well to have the parent window (the programmer of which knows very well that they are doing work prior to opening a child) say "look, don't let any events (except perhaps damage) come through while I do this dialog thing". In our case, it is not necessary to apply the event filtering to all windows known to the WindowManager. In fact, because *all* the application windows are in the same WindowManager this would probably be bad for us. Perhaps, though, we need to have base code and associated patterns for handling both situations as both very clearly happen in the wild, as you and I can attest, Steve. >When making changes to the base, I > feel the riskiest change is an iv, then a method override, then an > extension method, then an addition of a shared var. Again, absolutely agreed. I do feel, though, that if I have to commit such evil (and I can't remember the last time I did), I'd rather Get It Right rather than just poke at the problem. It's all subjective, though, eh? > I define the windows that shouldn't get input events as those that are > open at the start of the long block. If the block itself opens dialogs, > they should get events; if it opens windows (non-modal), we might want > them to get input events. Understood. We have some windows that do need to keep getting events that are within the same WindowManager. > > It strikes me that these two methods should remove any events > > already in the WindowManager EventQueue for the subject > > ApplicationWindow after the filter block is in place and > > before the block given as an argument is evaluated. > > > > It looks like >>drainOutstandingEventsFor: aWindow should > > work, so I'll go with that. > > Offhand, I'd say it's wrong. You only want to drain input events, not > damage events, otherwise you can miss areas that need repainting. I've catered for two situations. One where a parent window can tolerate damage events while the child is open, and one where the parent can tolerate no events at all. In the latter case, we just have to put up with accumulating damage until the child closes, where upon I do a >>refresh to completely restore the parent. In the former case, we do allow damage events through while the child is open and I agree that the initial drain outstanding events should not drain the damage ones, but at present it does. I suspect we'll get away with this because the time window now between a event calling for a child and the filter being installed is tiny ... but that's no excuse. You are quite right. I hope the Cincom solution will deal with that :-) > You need something like I did, to process all damage events for all windows > while leaving the rest there. I don't understand why we would wish to process the damage events for all windows in the WindowManager explicitly. It they are left in the EventQueue, surely they will be processed in the natural course of things anyway. It seems that explicitly processing these events just changes the timing slightly. Also, might stopping to do the repainting of all windows noticeably slow down the opening of the child? > You'll also need to think about close events etc., which might be triggered > programmatically. Yeah. I don't think this will be a problem for us, but I'll certainly look out for that. Thanks for the pointer. > HTH, and good luck! Heh, yes. Luck does seem to play a part sometimes, doesn't it. :-/ Thanks Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
Re: refreshing
|
|
In reply to this post by Bruce Badger
Bruce,
>Comments on my kludge of a fix would be greatly appreciated. Well, it "sounds" interesting. I'd like to see the actual code. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Smalltalk Enables Success -- What Are YOU Using? |
Re: refreshing
|
|
In reply to this post by Steven Kelly
Steven,
>That's essentially what I did in my change to addEvent: in >WindowManager, and it works for me. As with Bruce, I'd like to see if we can resolve this issue. Can you send me your code also so I can look at it. Maybe between Bruce's code and yours we can find an answer. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Smalltalk Enables Success -- What Are YOU Using? |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |