Re: [fltk.coredev] Fl_Choice initiates infinite loop

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
Previous Message ]New Message | Reply ]Next Message ]

Re: Fl_Choice initiates infinite loop Albrecht Schlosser 10:10 Jun 17 top right image
On 6/17/22 13:16 imm wrote:
On Fri, 17 Jun 2022 at 11:44, Albrecht Schlosser wrote:
On 6/17/22 01:58 Bill Spitzak wrote:
I think what is happening is the RELEASE event is getting lost, so the
counter thinks the button is pressed and keeps incrementing.
Yes, that was my first thought too and my first demo program opened a
modal window in the callback which directs the FL_RELEASE event to the
modal window and thus it is lost for the Fl_Counter widget. But this is
only one of the issues.

So... I haven't really been following this, but I'm concerned that
having a callback that runs for a significant time period might be a
tricky problem to solve anyway.

Yes, sure, but the library should handle it gracefully - as far as possible.

Whilst the button callback is "in flight" it seems that there could,
potentially, always be a risk of missing some events being delivered.
I think Windows tends to queue 'em all up, but I'm not sure to what
extent that happens for other OS, or how robust that really is...
Certainly on Windows if you block event delivery for "long enough"
things can start to get weird...

So it is useful to understand how/why the release [typo corrected] event is getting lost
but I' also concerned that whatever we do may not be able to fix all
the cases.

Most of the issues is meanwhile well understood (by me ;-) ).

One point was that the current timeout handling could cause repeated timeouts to fire again and again w/o intervening event handling which - in this case - would miss the FL_RELEASE event because all the timeouts ran in sequence based on just the button click.

To be more specific: if the timeout callback takes 50 ms and then calls Fl::repeat_timeout(0.1, ...), what should happen? For the best accuracy the new timer is internally corrected to trigger after 100 ms - 50 ms = 50 ms. This has always been the case on Linux but not on other platforms.

In our case the repetition timeout is 0.1 seconds. What if the callback takes more than 0.1 seconds? In this case Fl::repeat_timeout() would calculate 0 or a negative value which triggers the timer immediately. This is basically what happened in my demo program. The fact (bug) that the next timer callback could be called w/o intervening event handling caused the problem that the FL_RELEASE event would never be seen as long as the timer would repeat. This bug has been fixed now.

... but it would be possible for the counter to check if the mouse is
currently held down before repeating the timeout.
That's something I'm definitely going to look at.
Though, reading this (and not knowing what is happening underneath!) I
was concerned that this may itself induce some aberrant behaviours...

I did this in another commit which I pushed as well. I didn't find another way to make sure that the Fl_Counter widget gets all necessary events. Why? The simple case that the callback opens a modal window (e.g. fl_message()) would redirect all following events including FL_RELEASE to that modal window and thus eclipse the FL_RELEASE event from the Fl_Counter widget. Maybe we could use FL_LEAVE but I'm not sure that this would be delivered in this case.

Once the blocking of the event handling was fixed I could rely on the current Fl::event_state() info about mouse buttons etc.. Although this is not 100% bullet-proof it will usually be enough to terminate the repetition of Fl_Counter callbacks which are based on an internal state variable which in turn needs the FL_RELEASE event or some other events to reset.

Unless someone else has better ideas how to solve this issue this is now committed and should suffice.

There's still an open issue on macOS only which is described in GitHub issue #450 though. I have no idea what's going on in this case.

You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit
Direct Link to Message ]
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.