\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 a frame or a dialog, wxWindows calls \helpref{wxWindow::Close}{wxwindowclose}. This
+in a frame or a dialog, wxWidgets calls \helpref{wxWindow::Close}{wxwindowclose}. This
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
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
\wxheading{What should I do to upgrade my 1.xx OnClose to 2.0?}
-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
\wxheading{How do I exit the application gracefully?}
-A wxWindows application automatically exits when the designated top window, or the
+A wxWidgets 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
is a virtual function, not an event handler).