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 Rob McDonald 09:56 Jun 16 top right image
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,



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 ''.