corrected EVT_NOTIFY[_RANGE] docs (bug 1439078)

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

diff --git a/docs/latex/wx/tdebug.tex b/docs/latex/wx/tdebug.tex
index 76ab37d3db88f8715a40f7f500c28f01febfa6e4..dc73ccef8f094885f903ecd1b393773115112150 100644 (file)
--- a/docs/latex/wx/tdebug.tex
+++ b/docs/latex/wx/tdebug.tex
@@ -3,9 +3,9 @@
 Classes, functions and macros: \helpref{wxDebugContext}{wxdebugcontext}, \helpref{wxObject}{wxobject}, \helpref{wxLog}{wxlog},
 \rtfsp\helpref{Log functions}{logfunctions}, \helpref{Debug macros}{debugmacros}
 
-Various classes, functions and macros are provided in wxWindows to help you debug
-your application. Most of these are only available if you compile both wxWindows,
-your application and {\it all} libraries that use wxWindows with the \_\_WXDEBUG\_\_ symbol
+Various classes, functions and macros are provided in wxWidgets to help you debug
+your application. Most of these are only available if you compile both wxWidgets,
+your application and {\it all} libraries that use wxWidgets with the \_\_WXDEBUG\_\_ symbol
 defined. You can also test the \_\_WXDEBUG\_\_ symbol in your own applications to execute
 code that should be active only in debug mode.
 
@@ -16,13 +16,13 @@ various static functions and variables. It allows you to dump all objects to tha
 check memory for errors.
 
 It is good practice to define a \helpref{wxObject::Dump}{wxobjectdump} member function for each class you derive
-from a wxWindows class, so that \helpref{wxDebugContext::Dump}{wxdebugcontextdump} can call it and
+from a wxWidgets class, so that \helpref{wxDebugContext::Dump}{wxdebugcontextdump} can call it and
 give valuable information about the state of the application.
 
 If you have difficulty tracking down a memory leak, recompile
 in debugging mode and call \helpref{wxDebugContext::Dump}{wxdebugcontextdump} and \helpref{wxDebugContext::PrintStatistics}{wxdebugcontextprintstatistics} at
 appropriate places. They will tell you what objects have not yet been
-deleted, and what kinds of object they are. In fact, in debug mode wxWindows will automatically
+deleted, and what kinds of object they are. In fact, in debug mode wxWidgets will automatically
 detect memory leaks when your application is about to exit, and if there are any leaks,
 will give you information about the problem. (How much information depends on the operating system
 and compiler -- some systems don't allow all memory logging to be enabled). See the
@@ -36,8 +36,8 @@ find difficult-to-detect memory leaks (objects are not
 deallocated), overwrites (writing past the end of your object) and
 underwrites (writing to memory in front of the object).
 
-If debugging mode is on and the symbol wxUSE\_GLOBAL\_MEMORY\_OPERATORS is set
-to 1 in setup.h, 'new' is defined to be:
+If debugging mode is on and the symbols wxUSE\_GLOBAL\_MEMORY\_OPERATORS and
+wxUSE\_DEBUG\_NEW\_ALWAYS are set to 1 in setup.h, 'new' is defined to be:
 
 {\small
 \begin{verbatim}
@@ -45,7 +45,7 @@ to 1 in setup.h, 'new' is defined to be:
 \end{verbatim}
 }%
 
-All occurrences of 'new' in wxWindows and your own application will use
+All occurrences of 'new' in wxWidgets and your own application will use
 the overridden form of the operator with two extra arguments. This means that the debugging
 output (and error messages reporting memory problems) will tell you what
 file and on what line you allocated the object. Unfortunately not all
@@ -114,7 +114,7 @@ allocations done after the checkpoint will be dumped.
 
 You can use wxDebugContext if \_\_WXDEBUG\_\_ is defined, or you can use it
 at any other time (if wxUSE\_DEBUG\_CONTEXT is set to 1 in setup.h). It is not disabled
-in non-debug mode because you may not wish to recompile wxWindows and your entire application
+in non-debug mode because you may not wish to recompile wxWidgets and your entire application
 just to make use of the error logging facility.
 
 Note: wxDebugContext::SetFile has a problem at present, so use the default stream instead.