Confused about wxWindow::Update() vs Refresh()

[Paul Melis]

Vadim Zeitlin wrote:

>On Fri, 15 Feb 2008 11:31:27 +0100 Paul Melis <paul at science.uva.nl> wrote:
>
>PM> I have a situation in which an event handler (File -> Open) starts the 
>PM> processing of some data by an external library. The library provides 
>PM> progress callbacks which I'm using to drive a progress bar.
>PM> But how can I force redrawing of the progress bar immediately without 
>PM> using Yield()? Is this possible at all?
>
> It's possible to redraw it without using wxYield() but it's not possible
>to handle the clicks on the (optional) "Cancel" button without it. So if
>you use this button you have no choice but to call wxYield() unfortunately.
>
>[...]
>  
>
>PM> The second part of the sentence "Notice that this function doesn't 
>PM> refresh the window and does nothing if the window hadn't been already 
>PM> repainted." is extremely confusing. Update() does nothing if there has 
>PM> NOT already been a repaint?? Should I actually read this as "This 
>PM> function doesn't refresh the window (call Refresh() for that first). 
>PM> This function does nothing if the window already has been repainted"?
>
> It should, and it has been corrected some time ago, see
>
>http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin_wxwindow.html#wxwindowupdate
>  
>
Ah, much clearer :)

>PM> It seems that calling Refresh() on the progress first, to force it to 
>PM> repaint, followed by a call to Update() would do the trick but it 
>PM> doesn't (i.e. no redrawing takes place).
>PM> 
>PM> This is with wxGTK (2.6) b.t.w.
>
> Please try 2.8 as I don't think anybody is going to look at 2.6. But if it
>still doesn't work in 2.8 it's a bug which needs fixing.
>  
>
Thanks, 2.8 did the trick. The application now also noticeably processes 
the input faster. I guess this must be because the progress callbacks 
now update the progress bar widget immediately without starting a new 
event loop (like the previous version using wxYield did).

Regards,
Paul