refresh - from background processes?

>
> Using a dialog is also the way we ended up going. What we wanted was a
> progress window with a gauge and a little transcript. The progress
> window would be opened for long blocks, and while it was open the UI of
> other windows should repaint if obscured, but not accept any input (nor
> should they buffer the input and execute it at the end). The long block
> should be able to open other windows, e.g. dialogs, which would accept
> input. I've spent probably a couple of weeks in total on this problem,
> and it's been rather frustrating (I can see why Bruce ended up with
> method names like # openTheDialogNowDamnit!).
>  
> I got things working about 98% with a normal window, but there were
> still occasional problems like events being leaked in certain cases
> (various XP look widgets do horrid stuff with responding to mouse over,
> for instance, and sometimes dialogs opened during the long block would
> have their buttons invisible, or not respond to input). I also made it
> possible that a window could choose to be refreshed from a cached bitmap
> of its contents, rather than the normal redraw (e.g. if the long block
> was changing the model objects the window needed to display itself). The
> results are published as RefreshingDisplayPolicy 1.3.1 in the public Store.
>  
> Next I tried making the progress window a dialog, and that helped - now
> Windows handled a lot of the issues, and we were just left handling the
> VW problems while opening and closing the progress dialog, and while
> opening dialogs during the long block. The main changes were to
> WindowManager>>addEvent: (to not add unwanted input events to the queue)
> and ApplicationDialogController>>eventLoop (to process the next
> non-input event and remove it from the queue, whilst leaving the rest of
> the queue unchanged). There's also a bug correction for
> TextCollectorView>>update:, which leaks events, and WinXPTriggerButton,
> which UHEs when trying to process old ExitEvents.
>  
> The code for the dialog version references our progress dialog and
> global ProgressValueHolder, so I haven't published it to the public
> store. If anyone wants to take a look, I'd be happy to email it: it
> would be easy enough for you to substitute our dialog with your own. It
> would be good to get something like this working and available in VW,
> since it seems like functionality most non-trivial apps will need these
> days.
>  
> Cheers,
> Steve
>  
>
>     -----Original Message-----
>     From: Stewart MacLean [mailto:[hidden email]]
>     Sent: 15 February 2006 09:34
>     To: [hidden email]
>     Subject: refresh - from background processes?
>
>     Hi Bruce et al,
>
>      
>
>     I’m not sure it’s the same problem but, coincidentally, I’m having
>     problems updating the UI from a background process.
>
>      
>
>     I want the background process to open a dialog. However I don’t want
>     the dialog to block the background process.
>
>      
>
>     So I tried uiEventFor: (not uiEventNowFor: ). As a result I seem to
>     be running into similar problems with the dialog processing events
>     from subsequent background events. (the events are being processed
>     by the dialog, as it’s a child window of the argument window of
>     uiEventFor:).
>
>      
>
>     I’m wondering if there’s an accepted pattern for updating the UI
>     from a background process, without blocking the background process?
>
>      
>
>     (I’m thinking of using a buffer and then using uiEventNowFor: later
>     to avoid the problem…)
>
>      
>
>     Cheers,
>
>      
>
>     Stewart
>
>      
>
>      
>