FLTK logo

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 Jun 16, 2022  
 
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?

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?

(2) Do you create another window in your event (callback) handling?

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

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:

(5a) Does it exhibit the same behavior on Linux?

(5b) Does it also do this in commit cf4a832e6, the one before 29d9e31c51e6c?

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.

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.

--
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/48e031e7-2c9f-8b53-046a-b2f1849c2c61%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

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