- @class wxLog
-
- wxLog class defines the interface for the @e log targets used by wxWidgets
- logging functions as explained in the @ref overview_log.
- The only situations when you need to directly use this class is when you want
- to derive your own log target because the existing ones don't satisfy your
- needs. Another case is if you wish to customize the behaviour of the standard
- logging classes (all of which respect the wxLog settings): for example, set
- which trace messages are logged and which are not or change (or even remove
- completely) the timestamp on the messages.
-
- Otherwise, it is completely hidden behind the @e wxLogXXX() functions and
- you may not even know about its existence.
-
- @section overview_wxLog_deriving Deriving your own log target
-
- There are two functions which must be implemented by any derived class to
- actually process the log messages: DoLog() and
- DoLogString(). The second function receives a string
- which just has to be output in some way and the easiest way to write a new log
- target is to override just this function in the derived class. If more control
- over the output format is needed, then the first function must be overridden
- which allows to construct custom messages depending on the log level or even
- do completely different things depending on the message severity (for example,
- throw away all messages except warnings and errors, show warnings on the
- screen and forward the error messages to the user's (or programmer's) cell
- phone - maybe depending on whether the timestamp tells us if it is day or
- night in the current time zone).
- There also functions to support message buffering. Why are they needed?
- Some of wxLog implementations, most notably the standard wxLogGui class,
- buffer the messages (for example, to avoid showing the user a zillion of modal
- message boxes one after another -- which would be really annoying).
- Flush() shows them all and clears the buffer contents.
- This function doesn't do anything if the buffer is already empty.
- See also:
- @li Flush()
- @li FlushActive()
-
- @section overview_wxLog_Trace_Masks Using trace masks
-
- The functions below allow some limited customization of wxLog behaviour
- without writing a new log target class (which, aside from being a matter of
- several minutes, allows you to do anything you want).
- The verbose messages are the trace messages which are not disabled in the
- release mode and are generated by wxLogVerbose(). They
- are not normally shown to the user because they present little interest, but
- may be activated, for example, in order to help the user find some program
- problem.
- As for the (real) trace messages, their handling depends on the settings of
- the (application global) @e trace mask which can either be specified using
- SetTraceMask(), GetTraceMask() and wxLogTrace() which takes an integer mask
- or using AddTraceMask() for string trace masks.
- The difference between bit-wise and string trace masks is that a message using
- integer trace mask will only be logged if all bits of the mask are set in the
- current mask while a message using string mask will be logged simply if the
- mask had been added before to the list of allowed ones.
- For example,
-
- @code
- wxLogTrace( wxTraceRefCount|wxTraceOleCalls, "Active object ref count: %d", nRef );
- @endcode
-
- will do something only if the current trace mask contains both
- @c wxTraceRefCount and @c wxTraceOle, but
-
- @code
- wxLogTrace( wxTRACE_OleCalls, "IFoo::Bar() called" );
- @endcode
-
- will log the message if it was preceded by
-
- @code
- wxLog::AddTraceMask( wxTRACE_OleCalls);
- @endcode