These functions, declared in <FL/Fl.H>, support deletion of widgets inside callbacks.
More...
These functions, declared in <FL/Fl.H>, support deletion of widgets inside callbacks.
Fl::delete_widget() should be called when deleting widgets or complete widget trees (Fl_Group, Fl_Window, ...) inside callbacks.
The other functions are intended for internal use. The preferred way to use them is by using the helper class Fl_Widget_Tracker.
The following is to show how it works ...
There are three groups of related methods:
- scheduled widget deletion
- widget watch list ("smart pointers")
- the class Fl_Widget_Tracker:
◆ clear_widget_pointer()
| void Fl::clear_widget_pointer |
( |
Fl_Widget const * |
w | ) |
|
|
static |
Clears a widget pointer in the watch list.
This is called when a widget is destroyed (by its destructor). You should never call this directly.
- Note
- Internal use only !
This method searches the widget watch list for pointers to the widget and clears each pointer that points to it. Widget pointers can be added to the widget watch list by calling Fl::watch_widget_pointer() or by using the helper class Fl_Widget_Tracker (recommended).
- See also
- Fl::watch_widget_pointer()
-
class Fl_Widget_Tracker
◆ delete_widget()
Schedules a widget for deletion at the next call to the event loop.
Use this method to delete a widget inside a callback function.
To avoid early deletion of widgets, this function should be called toward the end of a callback and only after any call to the event loop (Fl::wait(), Fl::flush(), Fl::check(), fl_ask(), etc.).
When deleting groups or windows, you must only delete the group or window widget and not the individual child widgets.
- Since
- FLTK 1.3.4 the widget will be hidden immediately, but the actual destruction will be delayed until the event loop is finished. Up to FLTK 1.3.3 windows wouldn't be hidden before the event loop was done, hence you had to hide() a window in your window close callback if you called Fl::delete_widget() to destroy (and hide) the window.
-
FLTK 1.3.0 it is not necessary to remove widgets from their parent groups or windows before calling this, because it will be done in the widget's destructor, but it is not a failure to do this nevertheless.
- Note
- In FLTK 1.1 you must remove widgets from their parent group (or window) before deleting them.
- See also
- Fl_Widget::~Fl_Widget()
◆ do_widget_deletion()
| void Fl::do_widget_deletion |
( |
| ) |
|
|
static |
◆ release_widget_pointer()
| void Fl::release_widget_pointer |
( |
Fl_Widget *& |
w | ) |
|
|
static |
◆ watch_widget_pointer()
| void Fl::watch_widget_pointer |
( |
Fl_Widget *& |
w | ) |
|
|
static |
Adds a widget pointer to the widget watch list.
- Note
- Internal use only, please use class Fl_Widget_Tracker instead.
This can be used, if it is possible that a widget might be deleted during a callback or similar function. The widget pointer must be added to the watch list before calling the callback. After the callback the widget pointer can be queried, if it is NULL. If it is NULL, then the widget has been deleted during the callback and must not be accessed anymore. If the widget pointer is not NULL, then the widget has not been deleted and can be accessed safely.
After accessing the widget, the widget pointer must be released from the watch list by calling Fl::release_widget_pointer().
Example for a button that is clicked (from its handle() method):
set_changed();
do_callback();
if (!wp) {
} else {
clear_changed();
}
This works, because all widgets call Fl::clear_widget_pointer() in their destructors.
- See also
- Fl::release_widget_pointer()
-
Fl::clear_widget_pointer()
An easier and more convenient method to control widget deletion during callbacks is to use the class Fl_Widget_Tracker with a local (automatic) variable.
- See also
- class Fl_Widget_Tracker
