Re: Fl_Group/Fl_Tree/etc: document how to properly delete widgets/items from container widgets
Albrecht Schlosser
Jul 15, 2021
On 7/15/21 8:34 PM Bill Spitzak wrote:
It is pretty easy to write callbacks that will crash if some widget
has been deleted, which is the reason the deferred deletion is provided.
I agree. This has probably been done because I experienced crashes
around FLTK 1.1.5rcN when someone (IIRC Mike) changed code to reset the
changed() flag after the callback. At that time I was only a "user" of FLTK.
However if fltk or any of it's built-in widgets crashes because a
widget was deleted by a callback then this is a bug that should be fixed.
I agree again. This is the reason why the class Fl_Wiget_Tracker was
invented (by me) - after some work of Matt who made this class possible.
The conclusion is:
(1) if user code accesses deleted widgets in a callback it's their fault
- and we should warn not to do this.
(2) No FLTK widget must access a widget after the callback w/o checking
that it hasn't been deleted - which is done by using Fl_Widget_Tracker
and testing whether the widget still exists after calling the callback.
The only reason why Fl::delete_widget() would be needed today (in FLTK
1.4) is if something mentioned above is not taken care of. I hope I
found all cases and fixed the code in 1.1.x or at least in 1.3.x (I
don't remember exactly). Hence Fl::delete_widget() should never be
necessary WRT FLTK widgets, but users might still want it if their own
code is "broken" (or hard to fix).
Note that there's one fatal drawback of using Fl::delete_widget(): if
you ever call one of the standard FLTK dialogs or own code that uses
Fl::wait() inside a callback this could lead to unexpected (pemature)
widget deletion because Fl::wait() would delete all widgets scheduled
for deletion by Fl::delete_widget().
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
