| |
| |
Anonymous wrote:
If you derive a class from Fl_Window are you supposed to do a hide() in the destructor??
I notice they did that in the editor program
No, I think you're looking at the close_cb() function, which is not a destructor.
The close_cb() is Fl_Window's callback, which lets you hook into when someone
clicks the window manager's 'X' button in the title bar, so your program
can do things like check to see if the editor isn't saved, so you can post
a 'Quit without saving?' dialog to prevent closing the window.
The default is for the callback to hide the window.
The only destructor I see in the fltk/test/editor.cxx is for the EditWindow
which delete's the search/replace dialog, which is a separate window.
"The destructor also deletes all the children. This allows a whole tree
to be deleted at once, without having to keep a pointer to all the children in the user code. "
So if you do a "new Fl_Button" in a Fl_Double_Window derived constructor
you don't have to do a delete for that button in the destructor??
Yes; a "new Fl_Button" falls into that category of children
that are automatically destructed by Fl_Window's built in destructor.
You don't have to worry about destructing fltk widgets; their destructors
are called automatically when their parent window's destructor is called.
FLTK handles the destruction for you to ensure the children get destroyed
in the proper order, which is important esp. when widget hierarchies are
deep and complex. It does that work for you.
When you create the "new Fl_Button" in your constructor, FLTK's internals
automatically 'attach it' to the parent Fl_Window, keeping track of it
for later destruction.
It looks imbalanced to have a 'new Fl_Button' in your constructor
and nothing in your destructor, but it's actually correct in the case
of widgets added to windows, due to how FLTK manages the house keeping for you
on close.
[ Direct Link to Message ] | |
|
| |
