Ian MacArthur wrote:
> On 27 Apr 2011, at 16:33, chris tyt wrote:
>> sleep(3);
>
> I don't think your use of sleep() here is valid - it's a blocking call,
> so you will block the fltk event handling *whilst you are inside a callback
> event*
> and then all bets are off.
Actually, I think he's trying to use sleep as a way to easily
demonstrate
the issue of events lining up on a de-activated widget, and wanting to
make
sure the events accumulated while the widget is deactivated are properly
ignored, even if the actual app time is relatively short.
The events are lined up in the event buffer while the widget is
deactivated,
and he wants to make sure the events get processed while the widget is
deactivated, which means calling Fl::wait() to make sure the events
are processed before the widget is re-activated.
He was calling Fl::flush() (which only flushes graphics IIRC)
and has no effect on processing queued events, whereas Fl::wait()
will do both, which is what is needed here to get the queued events
to be processed before the re-activation.
Mainly a synchronization issue.
I can think of a lot of situations where an operation will 99% of the
time
react quickly (in millisecs) but once in a blue moon will take a
loooong time,
and during that time, you don't want things to queue up for your
deactivated widget.
Resolving a URL or database access are two I can think of offhand (and
should
likely use threads, but for a version 1.0 release might be skipped
until one
has the time to handle all that), or even a situation where a machine
under load
(ie. not an issue of the app at all) can have the same effect.
Deactivating/reactivating the widget is a good de-bouncing technique,
similar to the electrical equivalent of de-bouncing switches. So I think
what the OP is asking about is OK, and easily solved with Fl::wait().
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
