DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2627 Version: 1.4-feature Agreed. One more point, though, for later reference: Kurt (the OP) mentioned in fltk.development that some other application (in his case a WM, but maybe also an unrelated application that doesn't own the window) could call DestroyWindow() for a FLTK window. I don't know if this is possible, but if... In this case FLTK would probably receive the DestroyNotify event for a window it didn't destroy (hide) itself. As I said before, I doubt that sending an FL_CLOSE event would be correct here, because this would eventually call the window's callback, and this is defined so that the user would have a choice to reject it and don't hide the window. I *believe* that just calling Fl_Window::hide() would be more appropriate here, and that checking the internal status, whether the window is still shown (in the list of shown windows) would be enough to make sure that we don't get into a recursion or something like that... OTOH, *if* this is possible, then this would be a way to circumvent the window's close callback that is intended to give the application the chance to do some cleanup (e.g. ask the user to save a file), and this could seriously break the application logic. Link: http://www.fltk.org/str.php?L2627 Version: 1.4-feature _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
