| |
| |
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 fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/cdbd73c4-2392-fef1-d5bb-6d0244532334%40online.de.
[ Direct Link to Message ] | |
|
| |
