DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L1873 Version: 1.1-current This is a nasty one. 1: window is shown, focus goes to Fl_Input 2: press ESC, default_atclose calls hide() 3: hide() fixes focus, calling FL_LEAVE 4: FL_LEAVE causes Fl_Input to generate its callback 5: now enter the fl_ask's innards, re-entering Fl::wait 6: move the mouse over the main window 7: motion event is delivered to the window, which has "i" set to 0 to avoid drawing 8: watch it die! In general, it's true that FL_HIDE should _not_ draw to the window, however I think we must not remove the xid handler until all events have been dispatched. It is possible that, during recursive behavior, other events gets generated. I don't think checking shown() for every callback ever made is a good idea. This basically requires to move "i = 0" from Fl.cxx:935 to somewhere after Fl.cxx:956:handle(FL_HIDE);. This would also remove the need of the invasive cursor handling stuff in this function, that could be moved in the respective widget's FL_HIDE code. SVN reveals this code is pretty old, so I'm unsure about the requirement of having "i = 0;" set as soon. Any comment? I'm attaching a patch that fixes the recursive events sent to dying windows on carbon. It seems that the default carbon handler already checked for this, but not the mouse/activation/wheel handler. The patch fixes THIS issue, but I strongly suggest to revisit this behavior. Link: http://www.fltk.org/str.php?L1873 Version: 1.1-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
