refreshing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

refreshing

Bruce Badger
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/

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Bruce Badger
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/

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Dennis smith-4
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

Reply | Threaded
Open this post in threaded view
|

RE: refreshing

Terry Raymond
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/

Reply | Threaded
Open this post in threaded view
|

RE: refreshing

Steven Kelly
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/
>
>

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Bruce Badger
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/

Reply | Threaded
Open this post in threaded view
|

RE: refreshing

Terry Raymond
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/
> >
> >

Reply | Threaded
Open this post in threaded view
|

RE: refreshing

Thomas Brodt

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/
> > >
> > >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Bruce Badger
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

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Reinout Heeck-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Travis Griggs

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

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Samuel S. Shuster <sames@interaccess.com>
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?

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Bruce Badger
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/

Reply | Threaded
Open this post in threaded view
|

RE: refreshing

Terry Raymond
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/

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Bruce Badger
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/

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Bruce Badger
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/

Reply | Threaded
Open this post in threaded view
|

RE: refreshing

Steven Kelly
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

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Bruce Badger
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/

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Samuel S. Shuster <sames@interaccess.com>
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?

Reply | Threaded
Open this post in threaded view
|

Re: refreshing

Samuel S. Shuster <sames@interaccess.com>
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?

12