FLTK logo

STR #1869

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 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

STR #1869

Application:FLTK Library
Duplicate Of:STR #1986
Status:3 - Active
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Avoid recursing event handlers (Fl::readqueue, Fl::check)
Created By:AlbrechtS
Assigned To:AlbrechtS
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size  
#1 AlbrechtS
04:46 Feb 12, 2008

Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
#1 AlbrechtS
04:46 Feb 12, 2008
If a timer event (e.g. fl_add_timeout) starts a user interaction with fl_message(), fl_alert() or maybe others, the program hangs completely (no user interaction works), and the program window can't be closed.

Obviously, events get delivered to the programm, and get served, but nothing happens. There are no noticeable CPU activities, and windows doesn't tell you that the program/window doesn't react to events, if you click on the close button.

See attached test program. To test it, start the program, open the menu within 10 seconds after starting, and wait until the timer event calls fl_alert().

#2 AlbrechtS
04:47 Feb 12, 2008
Tested with fltk-1.1 svn (r5940) on Windows and Linux.
Same effect on both.
#3 StanS
08:24 Feb 12, 2008
As an aid to understanding the problem, note that this is a workaround:

void alert_cb(void *)
        Fl_Window* g = Fl::grab();
        fl_alert("this hangs, if a menu _is_open_ !");
#4 AlbrechtS
09:20 Feb 12, 2008
Thanks, Stan, this explains some of the effects, or maybe all.

I was just looking into Fl_Menu.cxx and saw that it uses Fl::grab(). At line 503, there is a comment:

// Fl_Menu_Item::popup(...)
// Because Fl::grab() is done, all events go to one of the menu windows.

And since fl_alert() et al. use Fl::readqueue() to get all events, this may be an explanation - and maybe your "workaround" would be the correct solution within fl_ask.cxx: innards() that makes use of Fl::readqueue().

Matt, Mike? Would this be the way to go?

#5 mike
11:58 Feb 12, 2008
Yes, probably we can just do that, however we should also document that Fl::readqueue() is incompatible with Fl::grab()...  
#6 AlbrechtS
03:38 Feb 13, 2008
okay, so here is a patch proposal, based on Stan's code:

fltk/src> svn diff fl_ask.cxx
Index: fl_ask.cxx
--- fl_ask.cxx  (revision 5940)
+++ fl_ask.cxx  (working copy)
@@ -203,6 +203,9 @@
+  // deactivate Fl::grab(), because it is incompatible with Fl::readqueue()
+  Fl_Window* g = Fl::grab();
+  Fl::grab(0);
   int r;
   for (;;) {
     Fl_Widget *o = Fl::readqueue();
@@ -212,6 +215,7 @@
     else if (o == button[2]) {r = 2; break;}
     else if (o == message_form) {r = 0; break;}
+  Fl::grab(g); // restore Fl::grab() window, if any
   return r;

#7 AlbrechtS
03:41 Feb 13, 2008
I forgot to mention: I tested this patch on Windows, and it does what I would expect: After closing the fl_alert() window, the menu stays open and is responsive.

#8 AlbrechtS
04:16 Feb 20, 2008
One more observation:

The proposed patch has the (IMHO minor) side effect, that you can drag the window away from an open menu, when the fl_alert() window is open. At least on windows.

Changing "Fl::grab(0);" to "Fl::grab(message_form);" fixes this (partially).

Tested on Windows: First, both windows can't be dragged away, while the fl_alert() window is open. But if you click on another application's window and then click on one of the test application's windows, then both window can be dragged, and the menu stays open and doesn't move. After closing the fl_alert() window, the menu can be clicked and works, and clicking somewhere else closes the menu.


Patch modification:

+  // deactivate Fl::grab(), because it is incompatible with Fl::readqueue()
+  Fl_Window* g = Fl::grab();
+  Fl::grab(0);


+  // deactivate Fl::grab(), because it is incompatible with Fl::readqueue()
+  Fl_Window* g = Fl::grab();
+  Fl::grab(message_form);
#9 matt
10:41 Feb 20, 2008
The patch below was applied to FLTK1.1.7x6034, but only partially fixes our problem. On OS X, for example, the alert will pop under an open menu, which is quite confusing. We should either change the way that recursing main loops are treated (forbid them), or think about delaying any window creation until after an Fl::grab(0( (which may also generate lockups).  
#10 fabien
00:16 Dec 04, 2008
IMHO, it may be confusing to let a menu popup open when displaying a message.
In some designs, the popup menu could close automatically when the mouse is released and in that case it would not work correctly to give the focus back to the popup menu.
So I think we probably should close any previously open menu before displaying a fl_message.
It may be interesting to have a menu api providing this facility.
#11 AlbrechtS
15:14 Jan 16, 2023
Assigned to myself.

I'm going to check this and related STR's (e.g. STR 1986).

Return to Bugs & Features | Post Text | Post File ]


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