| [ Return to Bugs & Features | Post Text | Post File | 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) |
Version: | 1.4-feature |
Created By: | AlbrechtS |
Assigned To: | AlbrechtS |
Fix Version: | Unassigned |
Update Notification: | |
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post 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().
Albrecht | |
|
#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::grab(0); fl_alert("this hangs, if a menu _is_open_ !"); Fl::grab(g); } | |
|
#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?
Albrecht | |
|
#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 @@ button[1]->take_focus(); message_form->hotspot(button[0]); message_form->show(); + // 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 message_form->hide(); icon->label(prev_icon_label); return r; fltk/src>
Albrecht | |
|
#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.
Albrecht | |
|
#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.
Albrecht
Patch modification:
+ // deactivate Fl::grab(), because it is incompatible with Fl::readqueue() + Fl_Window* g = Fl::grab(); + Fl::grab(0);
becomes:
+ // 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 ]
|
| |