]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/latex/wx/tlog.tex
SetTitle method (internal use only) changed to virtual OnSetTitle, added GetOpenedPag...
[wxWidgets.git] / docs / latex / wx / tlog.tex
index ae08edef53e3d812623c68a2b561a95a8061f5df..de86933c68e6fe38c8d320886b04657043c43ab4 100644 (file)
@@ -1,9 +1,7 @@
-\section{Log classes overview}\label{wxlogoverview}
+\section{wxLog classes overview}\label{wxlogoverview}
 
-Classes: \helpref{wxLog}{wxlog}, \helpref{wxLogStderr}{wxlogstderr},
- \helpref{wxLogOstream}{wxlogostream}, \helpref{wxLogTextCtrl}{wxlogtextctrl},
- \helpref{wxLogWindow}{wxlogwindow}, \helpref{wxLogGui}{wxloggui},
- \helpref{wxLogNull}{wxlognull}
+Classes: \helpref{wxLog}{wxlog}, wxLogStderr,
+wxLogOstream, wxLogTextCtrl, wxLogWindow, wxLogGui, wxLogNull
 
 This is a general overview of logging classes provided by wxWindows. The word
 logging here has a broad sense, including all of the program output, not only
@@ -39,13 +37,16 @@ wxLogInfo}).
 bar of the active or specified (as the first argument) \helpref{wxFrame}{wxframe} if it has one.
 \item{\bf wxLogSysError} is mostly used by wxWindows itself, but might be
 handy for logging errors after system call (API function) failure. It logs the
-specified message text as well as the last system error code ({\it errno} or
-{\it ::GetLastError()} depending on the platform) and the corresponding error
+specified message text as well as the last system error
+code ({\it errno} or {\it ::GetLastError()} depending on the platform) and the corresponding error
 message. The second form of this function takes the error code explitly as the
 first argument.
 \item{\bf wxLogDebug} is {\bf the} right function for debug output. It only
 does anything at all in the debug mode (when the preprocessor symbol
 \_\_WXDEBUG\_\_ is defined) and expands to nothing in release mode (otherwise).
+{\bf Tip:} under Windows, you must either run the program under debugger or
+use a 3rd party program such as \urlref{DbgView}{http://www.sysinternals.com} 
+to actually see the debug output.
 \item{\bf wxLogTrace} as {\bf wxLogDebug} only does something in debug
 build. The reason for making it a separate function from it is that usually
 there are a lot of trace messages, so it might make sense to separate them
@@ -54,7 +55,6 @@ version of this function takes a trace mask as the first argument which allows
 to further restrict the amount of messages generated.
 \end{itemize}
 
-% VZ: Julian, am I pushing too much here?
 The usage of these functions should be fairly straightforward, however it may
 be asked why not use the other logging facilities, such as C standard stdio
 functions or C++ streams. The short answer is that they're all very good
@@ -125,8 +125,8 @@ clear the log, close it completely or save all messages to file.
 \item{\bf wxLogNull} The last log class is quite particular: it doesn't do
 anything. The objects of this class may be instantiated to (temporarily)
 suppress output of {\it wxLogXXX()} functions. As an example, trying to open a
-non-existing file will usually provoke an error message, but if you for some
-reason it's unwanted, just use this construction:
+non-existing file will usually provoke an error message, but if for some
+reasons it's unwanted, just use this construction:
 
 {\small
 \begin{verbatim}