DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L1894 Version: 1.3-current Fabien, thanks for your comments. IMHO, your suggestion to remove a widget from its parent group in its destructor is the proper way to go. Meanwhile I have a working patch for our local FLTK version, that is in production code for some time now. However, I didn't find the time to propose an official patch - and I think that there is still at least one problem that needs to be solved for an official patch. See below. However, I don't like the idea of using a dictionary of valid widgets, as you propose. This seems to be contrary to the "Fast Light" principle of FLTK (think of using hundreds or thousands of widgets in an application). And I think that it wouldn't solve the problem shown below. Matt proposed "smart pointers" for some critical code paths, where widgets might be deleted during callbacks. IMHO, this should be used in FLTK's do_callback() logic, but that's another STR. The problem with fluid, that I mentioned at Mar 12, 2008, turned out to be another "kludge" in Fl_Value_Input. I could fix that, too. It's still a kludge, but maybe someone can find a better solution. The *unsolved* problem is: Because Fl_Group's destructor deletes all its children (recursively), there *_must_not_be_* static widgets as children in an Fl_Group or any of its children, when an Fl_Group is deleted, because these static widgets would be deleted, too. But then, at program exit, the static widgets' destructors would be called, and these static widgets would be deleted a second time. Hence, there would be a high probability of a crash at program exit. Thus, the "don't mix" rule (cf. Mar 12, 2008) would apply here. This would be something like: "The programmer is responsible for removing all static widgets that are children of an Fl_Group (or any of its children - that's recursive), before deleting an Fl_Group (or any Fl_Group derived widget)". This would be a new constraint, that is not documented in FLTK 1.1: If you add static widgets to a group, then remove them before deleting the group or any parent group. It's simple, but it has some potential to break existing code. OTOH, this would be good proramming practice, anyway. This rule would *not* apply to *automatic* (widget) variables that are destructed before their parent group, as documented already for FLTK 1.x. It works with composed widgets, too, because the child widgets would usually be deleted first. I'll try to create a patch for FLTK 1.3 soon. Or maybe for FLTK 1.1.9, if someone wants to test this with FLTK 1.1 code (because this is stable). The patch could be ported to FLTK 1.3 later, if confirmed (I assume that we wouldn't want to apply it to FLTK 1.1 ?). Link: http://www.fltk.org/str.php?L1894 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
