Re: [lmi] Wakeful sleep

[Vadim Zeitlin]

On Fri, 08 Nov 2013 14:03:43 +0000 Greg Chicares <address@hidden> wrote:

GC> Ideally, this pause would have two properties:
GC> 
GC> (1) The GUI still updates normally.
...
GC> (2) Except for the minimal activity in (1), no resources are consumed.
...
GC> How should I do this with wx? In HEAD (revision 5821), I'm just calling
GC> wxSleep(), which satisfies (2) but not (1). This alternative seems okay:
GC> 
GC>     for(int i = 0; i < 10 * seconds_to_pause; ++i)
GC>         {
GC>         wxMilliSleep(100);
GC>         wxTheApp && wxTheApp->Yield(true);
GC>         }
GC> 
GC> but is there a better way?

 This loop is not a bad solution for this particular problem, especially if
you use wxWindowDisabler to disable all the other windows except the one
which is supposed to accept input. It's not totally clear to me whether
this window is a wxProgressDialog or something else. If it is a
wxProgressDialog, then you actually could just call its Update() method
instead which calls Yield() internally already and also checks for the
Cancel button presses.

 The perfect solution wouldn't use Sleep() at all but would just disable
everything except the Cancel button and start a timer with a period of 10
seconds which would re-enable the rest of the UI on its expiration. But
this would require more extensive changes.

 Finally, let me remind you about the dangers of Yield(): when using it,
events can be dispatched in unforeseen circumstances and while the use of
wxWindowDisabler mitigates this for most types of the events, you should be
very careful if you have any "background" events, such as (other) timers,
threads, or IO operations (LMI doesn't use the latter, but I'm not sure
about the first two). Typical solution is to have a global "blocking" flag
which would be set before calling Yield() and checked by all the handlers
for these events to avoid (usually fatal) reentrancies which would result
from dispatching these events from inside this code.

 HTH,
VZ