On 28 Apr 2011, at 22:15, Greg Ercolano wrote: > 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.
Yes, I think you are right - but my point was that what he was doing (viz explicitly wedging the event queue) was not a valid thing to do, so the resulting behaviour was not a fltk bug per se, but a flaw in how it was being used. Since the event queue was wedged, it is almost inevitable that events would be queued up until it became unstuck again... > > 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. Agree, and using Fl::check() or Fl::wait(0) rather than Fl::flush() will (I think) produce the "correct" behaviour. But I still think the example was wrong - wedging in a callback is a Bad Thing to do. > > 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(). Yup. I think so. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
