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.1-current


IMHO, the code of Fl_Group::clear(), which is called from Fl_Group's
destructor, is too much "optimized", because it sets the children_ member
variable to 0 before deleting all the children. Then, it deletes all
children that _appear_ to be members of the group.

This effectively prevents child widgets from remove()ing themselves or any
related widgets from the group, when they are destroyed from
Fl_Group::clear(), because Fl_Group::remove() wouldn't find() the widget
in its list, because there are 0 children().

In svn -r 1878, it has already been tried to remove a widget from its
parent group and to remove the check in Fl_Group::clear():

-    // test the parent to see if child already destructed:
-    if (o->parent() == this) delete o;
+    delete o;

and in Fl_Widget.cxx:

-  parent_ = 0; // kludge to prevent ~Fl_Group from destroying again
+  if (parent_) parent_->remove(this);

(please note the comments that have been deleted),

but it has been reversed in svn -r 1883. The log says:

Revert Fl_Group/Fl_Widget destructor change - it doesn't work for
statically initialized widgets (like the widgets in a color chooser...)

I tried an improved solution that doesn't set children_ to 0, and uses a
while loop, something like:

  while (children_) {
    int old_children = children();
    Fl_Widget* o = child(0);  // or (children_-1);
    if (o->parent() == this) {
      remove(o);                        // remove widget from group
      delete o;                         // ... and delete it
    }
    else {
      remove(o);                        // remove only
    }
  }

to allow deleted widgets to delete and remove their dependent widgets in
their destructor, but this still has problems with statically initialized
widgets that are added to a group. I could see bad effects with fluid and
with menus.

I'm still testing, but what I found so far, seems to mean that correcting
this bug might have consequences for other (maybe user) code.

Albrecht


Link: http://www.fltk.org/str.php?L1894
Version: 1.1-current

_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Reply via email to