- @library{wxcore}
- @category{logging}
-
- @see wxLog::RemoveTraceMask, wxLog::GetTraceMasks
-*/
-class wxLog
-{
-public:
- /**
- Add the @a mask to the list of allowed masks for
- wxLogTrace().
-
- @see RemoveTraceMask(), GetTraceMasks()
- */
- static void AddTraceMask(const wxString& mask);
-
- /**
- Removes all trace masks previously set with
- AddTraceMask().
+ @section overview_wxLog_Trace_Masks 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()