mention that Wait() relocks the mutex before returning (patch 1482390)

[wxWidgets.git] / docs / latex / wx / tdelwin.tex

diff --git a/docs/latex/wx/tdelwin.tex b/docs/latex/wx/tdelwin.tex
index b5864727a87fea2c4a035393b2422cdd3ca2c6f5..da562d0c26cbdad168971559e7c1da50a59d1770 100644 (file)
--- a/docs/latex/wx/tdelwin.tex
+++ b/docs/latex/wx/tdelwin.tex
@@ -9,7 +9,7 @@ to close windows.
 \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
@@ -24,7 +24,7 @@ to the calling code.
 
 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
@@ -53,9 +53,6 @@ In other words, by default, the dialog {\it is not destroyed} (it might have bee
 on the stack, so the assumption of dynamic creation cannot be made).
 
 The default close event handler for wxFrame destroys the frame using Destroy().
-%
-%Under Windows, wxDialog defines a handler for \helpref{wxWindow::OnCharHook}{wxwindowoncharhook} that
-%generates a Cancel event if the Escape key has been pressed.
 
 \wxheading{What should I do when the user calls up Exit from a menu?}
 
@@ -70,8 +67,8 @@ the exit command altogether.
 
 \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
@@ -113,8 +110,9 @@ dialog, using the EVT\_CLOSE macro. The event handler function might look like t
 
 \wxheading{How do I exit the application gracefully?}
 
-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?}