\wxheading{What is the sequence of events in a window deletion?}
When the user clicks on the system close button or system close command,
\wxheading{What is the sequence of events in a window deletion?}
When the user clicks on the system close button or system close command,
in turn generates an EVT\_CLOSE event: see \helpref{wxCloseEvent}{wxcloseevent}.
It is the duty of the application to define a suitable event handler, and
decide whether or not to destroy the window.
If the application is for some reason forcing the application to close
in turn generates an EVT\_CLOSE event: see \helpref{wxCloseEvent}{wxcloseevent}.
It is the duty of the application to define a suitable event handler, and
decide whether or not to destroy the window.
If the application is for some reason forcing the application to close
-(\helpref{wxCloseEvent::CanVeto}{wxcloseeventcanveto} returns FALSE), the window should always be destroyed, otherwise there is the option to
+(\helpref{wxCloseEvent::CanVeto}{wxcloseeventcanveto} returns false), the window should always be destroyed, otherwise there is the option to
ignore the request, or maybe wait until the user has answered a question
before deciding whether it is safe to close. The handler for EVT\_CLOSE should
signal to the calling code if it does not destroy the window, by calling
ignore the request, or maybe wait until the user has answered a question
before deciding whether it is safe to close. The handler for EVT\_CLOSE should
signal to the calling code if it does not destroy the window, by calling
The wxCloseEvent handler should only call \helpref{wxWindow::Destroy}{wxwindowdestroy} to
delete the window, and not use the {\bf delete} operator. This is because
The wxCloseEvent handler should only call \helpref{wxWindow::Destroy}{wxwindowdestroy} to
delete the window, and not use the {\bf delete} operator. This is because
-for some window classes, wxWindows delays actual deletion of the window until all events have been processed,
+for some window classes, wxWidgets delays actual deletion of the window until all events have been processed,
since otherwise there is the danger that events will be sent to a non-existent window.
As reinforced in the next section, calling Close does not guarantee that the window
since otherwise there is the danger that events will be sent to a non-existent window.
As reinforced in the next section, calling Close does not guarantee that the window
Your application can either use \helpref{wxWindow::Close}{wxwindowclose} event just as
the framework does, or it can call \helpref{wxWindow::Destroy}{wxwindowdestroy} directly.
Your application can either use \helpref{wxWindow::Close}{wxwindowclose} event just as
the framework does, or it can call \helpref{wxWindow::Destroy}{wxwindowdestroy} directly.
that we definitely want to delete the frame and it cannot be vetoed.
The advantage of using Close instead of Destroy is that it will call any clean-up code
defined by the EVT\_CLOSE handler; for example it may close a document contained in
a window after first asking the user whether the work should be saved. Close can be vetoed
that we definitely want to delete the frame and it cannot be vetoed.
The advantage of using Close instead of Destroy is that it will call any clean-up code
defined by the EVT\_CLOSE handler; for example it may close a document contained in
a window after first asking the user whether the work should be saved. Close can be vetoed
on the stack, so the assumption of dynamic creation cannot be made).
The default close event handler for wxFrame destroys the frame using Destroy().
on the stack, so the assumption of dynamic creation cannot be made).
The default close event handler for wxFrame destroys the frame using Destroy().
-In wxWindows 1.xx, the {\bf OnClose} function did not actually delete 'this', but signaled
-to the calling function (either {\bf Close}, or the wxWindows framework) to delete
+In wxWidgets 1.xx, the {\bf OnClose} function did not actually delete 'this', but signaled
+to the calling function (either {\bf Close}, or the wxWidgets framework) to delete
or not delete the window.
To update your code, you should provide an event table entry in your frame or
or not delete the window.
To update your code, you should provide an event table entry in your frame or
-A wxWindows application automatically exits when the designated top window, or the
-last frame or dialog, is destroyed. Put any application-wide cleanup code in \helpref{wxApp::OnExit}{wxapponexit} (this
+A wxWidgets application automatically exits when the last top level window
+(\helpref{wxFrame}{wxframe} or \helpref{wxDialog}{wxdialog}), is destroyed. Put
+any application-wide cleanup code in \helpref{wxApp::OnExit}{wxapponexit} (this
is a virtual function, not an event handler).
\wxheading{Do child windows get deleted automatically?}
is a virtual function, not an event handler).
\wxheading{Do child windows get deleted automatically?}