On Thursday, June 16, 2022 at 7:54:21 AM UTC-7 Albrecht Schlosser wrote:
On 6/16/22 05:58 Rob McDonald wrote:
Clicking a Fl_Choice will kick off an infinite loop with the
choice repeatedly incrementing and firing off repeated events.
Instead of incrementing from 0 to 1, it goes to 1, 2, 3, 4, 5,
6, etc.
Hmm, this sounds more like Fl_Counter rather than Fl_Choice.
Correct?
Sorry about that -- my mistake. I don't know how I got so crossed up, my fingers must have auto-completed...
Yes, this is all about Fl_Counter (not choice).
This behavior depends on how long my program takes to respond
to the event. If my program is fast, the bug does not appear.
However, if my program takes 'too long', then the Fl_Choice
sends another event and it slips into the infinite loop.
I have a theory what *might* happen but I need more info.
(1) How are you handling the event? Are you using a callback?
Yes, I have a callback.
(2) Do you create another window in your event (callback) handling?
No additional FLTK calls should be made. No window should be opened.
(3) If yes, is this a modal window, maybe something like
fl_message() or fl_ask() or one of the other common dialogs?
(4) If it's not (2) or (3), can you describe what your program does
when it "takes 'too long' " ? Everything related to the event loop
(Fl::wait, Fl::check etc.) would be important, as well as info about
opening other windows.
I do a bunch of math to regenerate a Bezier surface. It should not touch anything else FLTK related. If the Bezier surface is a simple one (fast), the problem does not occur. If the case happens to be sufficiently complex (slow) then the problem does occur.
More questions below...
I manually bisected this behavior down to this commit:
29d9e31c51e6c Consolidate timeout handling across platforms
(#379) Albrecht Schlosser
The current tip of master (d8eb1f9ca46) still has this
problem.
I am on MacOS.
Would your program run on Linux too? If yes, can you please test it
on Linux and:
It will take me a while to get a Linux build set up to use an arbitrary version of FLTK. I will see what I can do.
(5a) Does it exhibit the same behavior on Linux?
(5b) Does it also do this in commit cf4a832e6, the one before
29d9e31c51e6c?
I'll let you know. On my Mac, cf4a832e6 works fine.
I have not tried to duplicate this in any of the test
programs - or to create a MWE. I'm hopeful that this will start
a conversation and perhaps someone will see the problem with the
new timeout handling code.
FWIW: I can replicate the issue with Fl_Counter (sic!) and calling
fl_message() in the callback.
Minimal test case (counter.cxx) attached.
You might just put a sleep of some sort -- my expectation is that a wait on the order of one second is enough to get the loop going.
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.
I will give it a shot and report back. Thanks,
Rob
