On 7/13/21 2:36 PM, Greg Ercolano wrote:
Our docs for Fl_Group should probably both describe and show
for how to delete widgets from the group (i.e. remove() and
destroy), showing proper
techniques especially in contexts where one has to be careful (or
used to have to be),
such as when deleting from callbacks vs. event handlers vs. other
Since the best way to get traction on this is to suggest
a change and seek input, as it's easier to make corrections to
someone else's suggestion than to suggest something from scratch.
For Fl_Group, we could perhaps add a section to the class
description, something along the lines of (I'm not actually the
one to write this, as I'm not sure all the ins and outs of when we
supported what.. I think we used to have an article about this but
I couldn't find it):
Removing vs. Deleting Children
..and include some example code showing the proper use in a
callback() vs handle() vs other contexts. Again, I'm probably not
the one to write this, as I'm not familiar with all the internals
and possible gotchyas.
Child widgets can be removed from the group
without destruction using remove(int) or
remove(Fl_Widget*), allowing the widget to remain allocated
so it can later be reparented elsewhere.
To delete as well as destroy a child widget, you can use any
which will schedule destruction on the next iteration of
the app loop
- In fltk 1.3.x (and up, 'x' unknown) you can simply use
the c++ 'delete' operator to destroy the
widget, and that automatically schedules it for removal
just like Fl::delete_widget()
- In fltk 1.1.x (and back) order of execution was
important; you had to use Fl_Group::remove() first, then
Similarly, docs for Fl_Browser::remove() and Fl_Tree::remove()
should elaborate on how they also
destroy the items, so as not to be confused with
Fl_Group::remove() (which does not), and in the
case of Fl_Tree, what happens with Fl_Widget's that have been
associated with tree items, and how
to properly reassign or destroy those.
This should be easy, just a small elaboration to the
existing docs (in green):
Remove entry for given line number, making the browser one line shorter.
This frees the memory associated with the browser item immediately.
You must call redraw() to make any changes visible.
Remove the specified 'item' from the tree.
assigned to the item with Fl_Tree_Item::widget(),
To destroy an FLTK widget assigned to the item, you can do that cleanly this way:
remove() frees the memory associated with the specified Fl_Tree_Item immediately.
remove() does not affect any FLTK widget
'item' may not be NULL. If the item has children, all those are removed too.
If item being removed has focus, no item will have focus.
// Delete the Fl_Tree_Item 'item' and any associated FLTK widget
Fl_Widget *w = item->widget(); // save any widget for the item
tree->remove(item); // remove the item, destroying it
if ( w ) Fl::delete_widget(w); // delete the widget last, if there was one
For more info, see Fl_Group section on deleting FLTK child widgets.
Note that after a remove(), any widget assigned to the item will remain a child
of Fl_Tree's Fl_Group, which will continue to 'own' the widget.
This allows the
widget to be reassigned to another item without having to recreate it. Destroying
the tree will automatically destroy any child fltk widgets.
I think specific details regarding proper deleting of FLTK
widgets should appear
There may be other widgets besides Fl_Browser and Fl_Tree that may
need elaboration on whether memory is freed or not with methods
only in Fl_Group, and other docs simply refer to that
documenation as needed,
so there aren't multiple descriptions of the process.
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/98b9449d-29f8-9041-828b-aab4e74add01%40gmail.com.
[ Direct Link to Message ]