|
|
On 6/16/22 20:00 Rob McDonald wrote:
On Thursday, June 16, 2022 at
7:54:21 AM UTC-7 Albrecht Schlosser wrote:
FWIW: I can replicate the issue with Fl_Counter (sic!)
and calling fl_message() in the callback.
Minimal test case (counter.cxx) attached.
Note that this test program exhibits the issue on Linux (git
current) and even before commit 29d9e31c51e6c. In fact, it's
also "broken" in FLTK 1.3 (git branch-1.3 latest). I didn't
bother to test on macOS (yet).
The fact that your program worked on macOS before changing
the timeout handling was supposedly only luck (not your
"fault" ;-) ). I didn't test my demo program on macOS yet,
awaiting your response with more info (see questions above).
FYI: My demo program can be "fixed" with both changes given
in the attached Fl_Counter.patch independently but this is
only a first proof of concept, not a real solution. However,
if your issue is similar to what I *guessed*
then you might want to test the patch and report if any one
of the changes (each one, separately) fixes the issue for
you.
Looking forward to your reply. TIA.
On my Mac, neither of the proposed fixes help the
situation.
I tried it with both fixes -- and it _maybe_ made a slight
improvement. The first time I pressed the button, I had
success, but the second time, it initiated the infinite loop.
OK, taking your earlier reply into account, I changed the demo
program to just (u)sleep() inside the callback and can trigger the
issue in a reprocucible way. This may be different than your real
case but it shows the issue. I'm attaching the modified demo program
counter.cxx. I know what is causing the issue, i.e. what happens
once it gets triggered, but I don't know yet how to fix it. I'll
look deeper into it tomorrow.
What I found out so far:
(1) My first assumption was that the Fl_Counter widget misses the
FL_RELEASE event and this can easily be demonstrated by opening a
modal window inside the callback. This is test case 1 [change '#if
(0)' to '#if (1)' ...] and can be fixed by my previously posted
patch.
(2) My new test program works by sleeping at least 100 ms inside the
callback. It seems necessary to hold the Fl_Counter button pressed
at least this time so the internal repeat timer gets called before
the FL_RELEASE event is delivered. This restarts the repeat timer
and triggers the (in this case potentially infinite) loop. This
happens on both Linux and macOS.
(3) Testing on the Mac I could confirm that commit cf4a832e6 (the
one before the timeout changes) does not have this issue.
(4) The problem is obviously in the code of Fl_Counter. It's not a
direct regression introduced by the timeout changes but it is
revealed by those.
(5) Another attempt to fix all known issues is my a new patch
Fl_Counter_v2.patch (attached). It's likely not the final solution
(fixing symptoms only) but it's a start.
Rob, can you please:
(a) test and (hopefully) confirm that this patch fixes your issue
too?
(b) open a GitHub Issue describing the issue in a short form so the
issue won't be forgotten. You can refer to this discussion for
further information [1]. I will investigate further and (hopefully,
again) find a proper solution later.
Thanks for finding the issue and your support in testing.
[1] Link:
https://groups.google.com/g/fltkcoredev/c/daKlBxeOJVk/m/D-MPHPiCAAAJ
--
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/e56dc3af-eace-0db2-c485-71ef93a7f0b6%40online.de.
[ Direct Link to Message ] | |
|
| |