DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L1986 Version: 1.1.9 wavexx wrote: "Note that X is _not_ frozen, is being locked via grab() on the menu, while event handling is currently processing another window (fl_ask's innards)." In the current svn version (r 6817), the following is done in fl_ask.cxx/innards(): message_form->show(); // deactivate Fl::grab(), because it is incompatible with Fl::readqueue() Fl_Window* g = Fl::grab(); if (g) // do an alternative grab to avoid floating menus, if possible Fl::grab(message_form); I think that this is the culprit, and I uploaded a patch file, see http://www.fltk.org/strfiles/1986/str_1986.patch . The correct part is that the existing grab(), if any, is terminated, but IMHO we must not do Fl::grab(message_form). On Windows this doesn't do much harm, but on Linux it is responsible for the described effect. When doing grab() with an open menu, a mouse click outside the menu dismisses it. That's okay. But here it is a grab() for an open fl_ask window, and this one simply ignores the click :-( This was introduced in svn -r 6035 (not 6034) as a fix for STR #1869. Having "floating menus" is IMHO a much minor issue than this "locking" experience under Linux. BTW.: Matt, did you mean that one can drag a window away from its open menu? Please test and confirm, I'd like to close the STR with the proposed fix. Maybe we can find an even better solution for 1.3, but this would need some redesign that can't be done for 1.1. Link: http://www.fltk.org/str.php?L1986 Version: 1.1.9 _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
