X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/0f358732e44d89af3d83c4b77e19d0963afa7c7e..3da93aae505563c359f58b357e6c79cd117c5320:/docs/latex/wx/tlog.tex?ds=sidebyside diff --git a/docs/latex/wx/tlog.tex b/docs/latex/wx/tlog.tex index ae08edef53..7db8f6c4ee 100644 --- a/docs/latex/wx/tlog.tex +++ b/docs/latex/wx/tlog.tex @@ -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 @@ -92,7 +92,7 @@ works. wxWindows has the notion of a {\it log target}: it's just a class deriving from \helpref{wxLog}{wxlog}. As such, it implements the virtual functions of the base class which are called when a message is logged. Only one log target -is {\it active} at any moment, this is the one used by \it{wxLogXXX()} +is {\it active} at any moment, this is the one used by {\it wxLogXXX()} functions. The normal usage of a log object (i.e. object of a class derived from wxLog) is to install it as the active target with a call to {\it SetActiveTarget()} and it will be used automatically by all subsequent calls @@ -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}