Applied patch [ 827011 ] Event-based processing of item tooltips in wxTreeCtrl

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

diff --git a/docs/latex/wx/tdelwin.tex b/docs/latex/wx/tdelwin.tex
index 4600573cd4af2ca65e5e8f84e3bec54dbc707981..b5864727a87fea2c4a035393b2422cdd3ca2c6f5 100644 (file)
--- a/docs/latex/wx/tdelwin.tex
+++ b/docs/latex/wx/tdelwin.tex
@@ -3,21 +3,21 @@
 Classes: \helpref{wxCloseEvent}{wxcloseevent}, \helpref{wxWindow}{wxwindow}
 
 Window deletion can be a confusing subject, so this overview is provided
 Classes: \helpref{wxCloseEvent}{wxcloseevent}, \helpref{wxWindow}{wxwindow}
 
 Window deletion can be a confusing subject, so this overview is provided

-to make it clear when and how you delete windows, or respond to user requests
+to help make it clear when and how you delete windows, or respond to user requests

 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
 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 turn generates an EVT\_CLOSE event: see \helpref{wxWindow::OnCloseWindow}{wxwindowonclosewindow}.
+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
 
 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
 ignore the request, or maybe wait until the user has answered a question

-before deciding whether it's safe to close. The handler for EVT\_CLOSE should
+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 
 \helpref{wxCloseEvent::Veto}{wxcloseeventveto}. Calling this provides useful information
 to the calling code.
 signal to the calling code if it does not destroy the window, by calling 
 \helpref{wxCloseEvent::Veto}{wxcloseeventveto}. Calling this provides useful information
 to the calling code.


@@ -27,17 +27,21 @@ 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,
 since otherwise there is the danger that events will be sent to a non-existent window.
 
 for some window classes, wxWindows 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
+will be destroyed. Call \helpref{wxWindow::Destroy}{wxwindowdestroy} if you want to be
+certain that the window is destroyed.
+

 \wxheading{How can the application close a window itself?}
 
 Your application can either use \helpref{wxWindow::Close}{wxwindowclose} event just as
 the framework does, or it can call \helpref{wxWindow::Destroy}{wxwindowdestroy} directly.
 \wxheading{How can the application close a window itself?}
 
 Your application can either use \helpref{wxWindow::Close}{wxwindowclose} event just as
 the framework does, or it can call \helpref{wxWindow::Destroy}{wxwindowdestroy} directly.

-If using Close(), you can pass a TRUE argument to this function to tell the event handler
+If using Close(), you can pass a true argument to this function to tell the event handler

 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

-by this process (return FALSE), whereas Destroy definitely destroys the window.
+by this process (return false), whereas Destroy definitely destroys the window.

 
 \wxheading{What is the default behaviour?}
 
 
 \wxheading{What is the default behaviour?}
 


@@ -45,13 +49,13 @@ The default close event handler for wxDialog simulates a Cancel command,
 generating a wxID\_CANCEL event. Since the handler for this cancel event might
 itself call {\bf Close}, there is a check for infinite looping. The default handler
 for wxID\_CANCEL hides the dialog (if modeless) or calls EndModal(wxID\_CANCEL) (if modal).
 generating a wxID\_CANCEL event. Since the handler for this cancel event might
 itself call {\bf Close}, there is a check for infinite looping. The default handler
 for wxID\_CANCEL hides the dialog (if modeless) or calls EndModal(wxID\_CANCEL) (if modal).

-In other words, by default, the dialog is not destroyed (it might have been created
+In other words, by default, the dialog {\it is not destroyed} (it might have been created

 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().

-
-Under Windows, wxDialog defines a handler for \helpref{wxWindow::OnCharHook}{wxwindowoncharhook} that
-generates a Cancel event if the Escape key has been pressed.
+%
+%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?}
 
 
 \wxheading{What should I do when the user calls up Exit from a menu?}
 


@@ -66,7 +70,7 @@ the exit command altogether.
 
 \wxheading{What should I do to upgrade my 1.xx OnClose to 2.0?}
 
 
 \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 signalled
+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
 or not delete the window.
 
 to the calling function (either {\bf Close}, or the wxWindows framework) to delete
 or not delete the window.