-\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
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
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
\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}