Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor wxLog documentation moving verbose parts to the wxLog overview and grouping similar wxLog functions together

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65103 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Francesco Montorsi
2010-07-25 11:53:54 +00:00
parent 128eed6c64
commit 54e280d860
2 changed files with 315 additions and 333 deletions
Download Patch File Download Diff File Expand all files Collapse all files

178
docs/doxygen/overviews/log.h
View File

@@ -10,24 +10,17 @@
@page overview_log wxLog Classes Overview
Classes:
@li wxLog
@li wxLogStderr
@li wxLogStream
@li wxLogTextCtrl
@li wxLogWindow
@li wxLogGui
@li wxLogNull
@li wxLogBuffer
@li wxLogChain
@li wxLogInterposer
@li wxLogInterposerTemp
@li wxStreamToTextRedirector
Classes: wxLog, wxLogStderr, wxLogStream, wxLogTextCtrl, wxLogWindow, wxLogGui, wxLogNull, wxLogBuffer,
wxLogChain, wxLogInterposer, wxLogInterposerTemp, wxStreamToTextRedirector
Table of contents:
@li @ref overview_log_introduction
@li @ref overview_log_enable
@li @ref overview_log_targets
@li @ref overview_log_mt
@li @ref overview_log_customize
@li @ref overview_log_tracemasks
@li @ref overview_log_timestamps
<hr>
@@ -41,43 +34,42 @@ as well as several standard implementations of it and a family of functions to
use with them.
First of all, no knowledge of wxLog classes is needed to use them. For this,
you should only know about @e wxLogXXX() functions. All of them have the same
syntax as @e printf() or @e vprintf() , i.e. they take the format string as the
first argument and respectively a variable number of arguments or a variable
argument list pointer. Here are all of them:
you should only know about @ref group_funcmacro_log "wxLogXXX() functions".
All of them have the same syntax as @e printf() or @e vprintf() , i.e. they
take the format string as the first argument and respectively a variable number
of arguments or a variable argument list pointer. Here are all of them:
@li wxLogFatalError which is like wxLogError, but also terminates the program
@li wxLogFatalError() which is like wxLogError(), but also terminates the program
with the exit code 3 (using @e abort() standard function). Unlike for all
the other logging functions, this function can't be overridden by a log
target.
@li wxLogError is the function to use for error messages, i.e. the messages
@li wxLogError() is the function to use for error messages, i.e. the messages
that must be shown to the user. The default processing is to pop up a
message box to inform the user about it.
@li wxLogWarning for warnings. They are also normally shown to the user, but
@li wxLogWarning() for warnings. They are also normally shown to the user, but
don't interrupt the program work.
@li wxLogMessage is for all normal, informational messages. They also appear in
@li wxLogMessage() is for all normal, informational messages. They also appear in
a message box by default (but it can be changed, see below).
@li wxLogVerbose is for verbose output. Normally, it is suppressed, but might
@li wxLogVerbose() is for verbose output. Normally, it is suppressed, but might
be activated if the user wishes to know more details about the program
progress (another, but possibly confusing name for the same function is
wxLogInfo).
@li wxLogStatus is for status messages. They will go into the status bar of the
@li wxLogStatus() is for status messages. They will go into the status bar of the
active or specified (as the first argument) wxFrame if it has one.
@li wxLogSysError is mostly used by wxWidgets itself, but might be handy for
@li wxLogSysError() is mostly used by wxWidgets 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 (@e errno or
::GetLastError() depending on the platform) and the corresponding error
Windows' @e GetLastError() depending on the platform) and the corresponding error
message. The second form of this function takes the error code explicitly
as the first argument.
@li wxLogDebug is @b the right function for debug output. It only does anything
at all in the debug mode (when the preprocessor symbol __WXDEBUG__ is
@li wxLogDebug() is @b the right function for debug output. It only does anything
at all in the debug mode (when the preprocessor symbol @c __WXDEBUG__ is
defined) and expands to nothing in release mode (otherwise).
@b Tip: under Windows, you must either run the program under debugger or
Note that under Windows, you must either run the program under debugger or
use a 3rd party program such as DebugView
(http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx)
to actually see the debug output.
@li wxLogTrace as wxLogDebug only does something in debug build. The reason for
@li wxLogTrace() as 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 from other debug
messages which would be flooded in them. Moreover, the second version of
@@ -177,10 +169,10 @@ works.
wxWidgets has the notion of a <em>log target</em>: it is just a class deriving
from 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 @e active at
any moment, this is the one used by @e 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 @e SetActiveTarget() and it will be used
automatically by all subsequent calls to @e wxLogXXX() functions.
any moment, this is the one used by @ref group_funcmacro_log "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 @e SetActiveTarget() and it will be used
automatically by all subsequent calls to @ref group_funcmacro_log "wxLogXXX() functions".
To create a new log target class you only need to derive it from wxLog and
override one or several of wxLog::DoLogRecord(), wxLog::DoLogTextAtLevel() and
@@ -237,28 +229,6 @@ normally. For this the wxLogChain, wxLogInterposer, and wxLogInterposerTemp can
be used.
@section overview_log_customize Logging Customization
To completely change the logging behaviour you may define a custom log target.
For example, you could define a class inheriting from wxLog which shows all the
log messages in some part of your main application window reserved for the
message output without interrupting the user work flow with modal message
boxes.
To use your custom log target you may either call wxLog::SetActiveTarget() with
your custom log object or create a wxAppTraits-derived class and override
CreateLogTarget() virtual method in it and also override wxApp::CreateTraits()
to return an instance of your custom traits object. Notice that in the latter
case you should be prepared for logging messages early during the program
startup and also during program shutdown so you shouldn't rely on existence of
the main application window, for example. You can however safely assume that
GUI is (already/still) available when your log target as used as wxWidgets
automatically switches to using wxLogStderr if it isn't.
The dialog sample illustrates this approach by defining a custom log target
customizing the dialog used by wxLogGui for the single messages.
@section overview_log_mt Logging in Multi-Threaded Applications
Starting with wxWidgets 2.9.1, logging functions can be safely called from any
@@ -277,5 +247,99 @@ Also notice that wxLog::EnableLogging() and wxLogNull class which uses it only
affect the current thread, i.e. logging messages may still be generated by the
other threads after a call to @c EnableLogging(false).
@section overview_log_customize Logging Customization
To completely change the logging behaviour you may define a custom log target.
For example, you could define a class inheriting from wxLog which shows all the
log messages in some part of your main application window reserved for the
message output without interrupting the user work flow with modal message
boxes.
To use your custom log target you may either call wxLog::SetActiveTarget() with
your custom log object or create a wxAppTraits-derived class and override
wxAppTraits::CreateLogTarget() virtual method in it and also override wxApp::CreateTraits()
to return an instance of your custom traits object. Notice that in the latter
case you should be prepared for logging messages early during the program
startup and also during program shutdown so you shouldn't rely on existence of
the main application window, for example. You can however safely assume that
GUI is (already/still) available when your log target as used as wxWidgets
automatically switches to using wxLogStderr if it isn't.
There are several methods which may be overridden in the derived class to
customize log messages handling: wxLog::DoLogRecord(), wxLog::DoLogTextAtLevel()
and wxLog::DoLogText().
The last method is the simplest one: you should override it if you simply
want to redirect the log output elsewhere, without taking into account the
level of the message. If you do want to handle messages of different levels
differently, then you should override wxLog::DoLogTextAtLevel().
Finally, if more control over the output format is needed, then the first
function must be overridden as it 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).
The @e dialog sample illustrates this approach by defining a custom log target
customizing the dialog used by wxLogGui for the single messages.
@section overview_log_tracemasks Using trace masks
Notice that the use of log trace masks is hardly necessary any longer in
current wxWidgets version as the same effect can be achieved by using
different log components for different log statements of any level. Please
see @ref overview_log_enable for more information about the log components.
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 currently
enabled trace masks: if wxLog::AddTraceMask() was called for the mask of the given
message, it will be logged, otherwise nothing happens.
For example,
@code
wxLogTrace( wxTRACE_OleCalls, "IFoo::Bar() called" );
@endcode
will log the message if it was preceded by:
@code
wxLog::AddTraceMask( wxTRACE_OleCalls);
@endcode
The standard trace masks are given in wxLogTrace() documentation.
@section overview_log_timestamps Timestamps
The wxLog::LogRecord() function automatically prepends a time stamp
to all the messages. The format of the time stamp may be changed: it can be
any string with % specifications fully described in the documentation of the
standard @e strftime() function. For example, the default format is
@c "[%d/%b/%y %H:%M:%S] " which gives something like @c "[17/Sep/98 22:10:16] "
(without quotes) for the current date.
Setting an empty string as the time format or calling the shortcut wxLog::DisableTimestamp(),
disables timestamping of the messages completely.
@note
Timestamping is disabled for Visual C++ users in debug builds by
default because otherwise it would be impossible to directly go to the line
from which the log message was generated by simply clicking in the debugger
window on the corresponding error message. If you wish to enable it, please
use SetTimestamp() explicitly.
*/

460
interface/wx/log.h
View File

@@ -1,6 +1,6 @@
/////////////////////////////////////////////////////////////////////////////
// Name: log.h
// Purpose: interface of wxLogWindow
// Purpose: interface of wxLog* classes
// Author: wxWidgets team
// RCS-ID: $Id$
// Licence: wxWindows licence
@@ -96,9 +96,11 @@ public:
@true to show the frame initially (default), otherwise
Show() must be called later.
@param passToOld
@true to process the log messages normally in addition to
logging them in the log frame (default), @false to only log them in the
log frame.
@true to process the log messages normally in addition to logging them
in the log frame (default), @false to only log them in the log frame.
Note that if no targets were set using wxLog::SetActiveTarget() then
wxLogWindow simply becomes the active one and messages won't be passed
to other targets.
*/
wxLogWindow(wxWindow* pParent, const wxString& szTitle, bool show = true,
bool passToOld = true);
@@ -584,145 +586,32 @@ public:
/**
@class wxLog
wxLog class defines the interface for the @e log targets used by wxWidgets
wxLog class defines the interface for the <em>log targets</em> 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.
needs.
Otherwise, it is completely hidden behind the @e wxLogXXX() functions and
you may not even know about its existence.
Otherwise, it is completely hidden behind the @ref group_funcmacro_log "wxLogXXX() functions"
and you may not even know about its existence.
@note For console-mode applications, the default target is wxLogStderr, so
that all @e wxLogXXX() functions print on @c stderr when @c wxUSE_GUI = 0.
@section log_derivingyours Deriving your own log target
There are several methods which may be overridden in the derived class to
customize log messages handling: DoLogRecord(), DoLogTextAtLevel() and
DoLogText().
The last method is the simplest one: you should override it if you simply
want to redirect the log output elsewhere, without taking into account the
level of the message. If you do want to handle messages of different levels
differently, then you should override DoLogTextAtLevel().
Finally, if more control over the output format is needed, then the first
function must be overridden as it 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 FlushActive()
@section log_tracemasks Using trace masks
Notice that the use of log trace masks is hardly necessary any longer in
current wxWidgets version as the same effect can be achieved by using
different log components for different log statements of any level. Please
see @ref overview_log_enable for more information about the log components.
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 currently
enabled trace masks: if AddTraceMask() was called for the mask of the given
message, it will be logged, otherwise nothing happens.
For example,
@code
wxLogTrace( wxTRACE_OleCalls, "IFoo::Bar() called" );
@endcode
will log the message if it was preceded by:
@code
wxLog::AddTraceMask( wxTRACE_OleCalls);
@endcode
The standard trace masks are given in wxLogTrace() documentation.
Finally, the @e wxLog::DoLog() function automatically prepends a time stamp
to all the messages. The format of the time stamp may be changed: it can be
any string with % specifications fully described in the documentation of the
standard @e strftime() function. For example, the default format is
"[%d/%b/%y %H:%M:%S] " which gives something like "[17/Sep/98 22:10:16] "
(without quotes) for the current date. Setting an empty string as the time
format or calling the shortcut wxLog::DisableTimestamp(), disables timestamping
of the messages completely.
See also
@li AddTraceMask()
@li RemoveTraceMask()
@li ClearTraceMasks()
@li GetTraceMasks()
@li IsAllowedTraceMask()
@li SetVerbose()
@li GetVerbose()
@li SetTimestamp()
@li GetTimestamp()
@li SetTraceMask()
@li GetTraceMask()
@li SetRepetitionCounting()
@li GetRepetitionCounting()
@note
Timestamping is disabled for Visual C++ users in debug builds by
default because otherwise it would be impossible to directly go to the line
from which the log message was generated by simply clicking in the debugger
window on the corresponding error message. If you wish to enable it, please
use SetTimestamp() explicitly.
@section log_target Manipulating the log target
The functions in this section work with and manipulate the active log
target.
Get/Set methods are used to install/query the current active target and,
finally, DontCreateOnDemand() disables the automatic creation of a standard
log target if none actually exists. It is only useful when the application
is terminating and shouldn't be used in other situations because it may
easily lead to a loss of messages.
See also:
@li GetActiveTarget()
@li SetActiveTarget()
@li DontCreateOnDemand()
@li Suspend()
@li Resume()
@library{wxcore}
@category{logging}
@see @ref overview_log
@see @ref overview_log, @ref group_funcmacro_log "wxLogXXX() functions"
*/
class wxLog
{
public:
/**
@name Trace mask functions
*/
//@{
/**
Add the @a mask to the list of allowed masks for wxLogTrace().
@@ -737,50 +626,49 @@ public:
*/
static void ClearTraceMasks();
/**
Returns the currently allowed list of string trace masks.
@see AddTraceMask().
*/
static const wxArrayString& GetTraceMasks();
/**
Returns @true if the @a mask is one of allowed masks for wxLogTrace().
See also: AddTraceMask(), RemoveTraceMask()
*/
static bool IsAllowedTraceMask(const wxString& mask);
/**
Remove the @a mask from the list of allowed masks for
wxLogTrace().
@see AddTraceMask()
*/
static void RemoveTraceMask(const wxString& mask);
//@}
/**
@name Log target functions
*/
//@{
/**
Instructs wxLog to not create new log targets on the fly if there is none
currently. (Almost) for internal use only: it is supposed to be called by the
application shutdown code.
currently (see GetActiveTarget()).
(Almost) for internal use only: it is supposed to be called by the
application shutdown code (where you don't want the log target to be
automatically created anymore).
Note that this function also calls ClearTraceMasks().
*/
static void DontCreateOnDemand();
/**
Globally enable or disable logging.
Calling this function with @false argument disables all log messages
for the current thread.
@see wxLogNull, IsEnabled()
@return
The old state, i.e. @true if logging was previously enabled and
@false if it was disabled.
*/
static bool EnableLogging(bool enable = true);
/**
Shows all the messages currently in buffer and clears it.
If the buffer is already empty, nothing happens.
If you override this method in a derived class, call the base class
version first, before doing anything else.
*/
virtual void Flush();
/**
Flushes the current log target if any, does nothing if there is none.
When this method is called from the main thread context, it also
flushes any previously buffered messages logged by the other threads.
When it is called from the other threads it simply calls Flush() on the
currently active log target, so it mostly makes sense to do this if a
thread has its own logger set with SetThreadActiveTarget().
*/
static void FlushActive();
/**
Returns the pointer to the active log target (may be @NULL).
@@ -798,6 +686,86 @@ public:
*/
static wxLog* GetActiveTarget();
/**
Sets the specified log target as the active one.
Returns the pointer to the previous active log target (may be @NULL).
To suppress logging use a new instance of wxLogNull not @NULL. If the
active log target is set to @NULL a new default log target will be
created when logging occurs.
@see SetThreadActiveTarget()
*/
static wxLog* SetActiveTarget(wxLog* logtarget);
/**
Sets a thread-specific log target.
The log target passed to this function will be used for all messages
logged by the current thread using the usual wxLog functions. This
shouldn't be called from the main thread which never uses a thread-
specific log target but can be used for the other threads to handle
thread logging completely separately; instead of buffering thread log
messages in the main thread logger.
Notice that unlike for SetActiveTarget(), wxWidgets does not destroy
the thread-specific log targets when the thread terminates so doing
this is your responsibility.
This method is only available if @c wxUSE_THREADS is 1, i.e. wxWidgets
was compiled with threads support.
@param logger
The new thread-specific log target, possibly @NULL.
@return
The previous thread-specific log target, initially @NULL.
@since 2.9.1
*/
static wxLog *SetThreadActiveTarget(wxLog *logger);
/**
Flushes the current log target if any, does nothing if there is none.
When this method is called from the main thread context, it also
flushes any previously buffered messages logged by the other threads.
When it is called from the other threads it simply calls Flush() on the
currently active log target, so it mostly makes sense to do this if a
thread has its own logger set with SetThreadActiveTarget().
*/
static void FlushActive();
/**
Resumes logging previously suspended by a call to Suspend().
All messages logged in the meanwhile will be flushed soon.
*/
static void Resume();
/**
Suspends the logging until Resume() is called.
Note that the latter must be called the same number of times as the former
to undo it, i.e. if you call Suspend() twice you must call Resume() twice as well.
Note that suspending the logging means that the log sink won't be be flushed
periodically, it doesn't have any effect if the current log target does the
logging immediately without waiting for Flush() to be called (the standard
GUI log target only shows the log dialog when it is flushed, so Suspend()
works as expected with it).
@see Resume(), wxLogNull
*/
static void Suspend();
//@}
/**
@name Log level functions
*/
//@{
/**
Returns the current log level limit.
@@ -808,48 +776,6 @@ public:
*/
static wxLogLevel GetLogLevel();
/**
Returns whether the repetition counting mode is enabled.
*/
static bool GetRepetitionCounting();
/**
Returns the current timestamp format string.
*/
static const wxString& GetTimestamp();
/**
@deprecated
Returns the current trace mask, see Customization() section for details.
*/
static wxTraceMask GetTraceMask();
/**
Returns the currently allowed list of string trace masks.
@see AddTraceMask().
*/
static const wxArrayString& GetTraceMasks();
/**
Returns whether the verbose mode is currently active.
*/
static bool GetVerbose();
/**
Returns @true if the @a mask is one of allowed masks for wxLogTrace().
See also: AddTraceMask(), RemoveTraceMask()
*/
static bool IsAllowedTraceMask(const wxString& mask);
/**
Returns true if logging is enabled at all now.
@see IsLevelEnabled(), EnableLogging()
*/
static bool IsEnabled();
/**
Returns true if logging at this level is enabled for the current thread.
@@ -863,32 +789,6 @@ public:
*/
static bool IsLevelEnabled(wxLogLevel level, wxString component);
/**
Remove the @a mask from the list of allowed masks for
wxLogTrace().
@see AddTraceMask()
*/
static void RemoveTraceMask(const wxString& mask);
/**
Resumes logging previously suspended by a call to Suspend().
All messages logged in the meanwhile will be flushed soon.
*/
static void Resume();
/**
Sets the specified log target as the active one.
Returns the pointer to the previous active log target (may be @NULL).
To suppress logging use a new instance of wxLogNull not @NULL. If the
active log target is set to @NULL a new default log target will be
created when logging occurs.
@see SetThreadActiveTarget()
*/
static wxLog* SetActiveTarget(wxLog* logtarget);
/**
Sets the log level for the given component.
@@ -919,6 +819,41 @@ public:
*/
static void SetLogLevel(wxLogLevel logLevel);
//@}
/**
@name Enable/disable features functions
*/
//@{
/**
Globally enable or disable logging.
Calling this function with @false argument disables all log messages
for the current thread.
@see wxLogNull, IsEnabled()
@return
The old state, i.e. @true if logging was previously enabled and
@false if it was disabled.
*/
static bool EnableLogging(bool enable = true);
/**
Returns true if logging is enabled at all now.
@see IsLevelEnabled(), EnableLogging()
*/
static bool IsEnabled();
/**
Returns whether the repetition counting mode is enabled.
*/
static bool GetRepetitionCounting();
/**
Enables logging mode in which a log message is logged once, and in case exactly
the same message successively repeats one or more times, only the number of
@@ -927,30 +862,9 @@ public:
static void SetRepetitionCounting(bool repetCounting = true);
/**
Sets a thread-specific log target.
The log target passed to this function will be used for all messages
logged by the current thread using the usual wxLog functions. This
shouldn't be called from the main thread which never uses a thread-
specific log target but can be used for the other threads to handle
thread logging completely separately; instead of buffering thread log
messages in the main thread logger.
Notice that unlike for SetActiveTarget(), wxWidgets does not destroy
the thread-specific log targets when the thread terminates so doing
this is your responsibility.
This method is only available if @c wxUSE_THREADS is 1, i.e. wxWidgets
was compiled with threads support.
@param logger
The new thread-specific log target, possibly @NULL.
@return
The previous thread-specific log target, initially @NULL.
@since 2.9.1
Returns the current timestamp format string.
*/
static wxLog *SetThreadActiveTarget(wxLog *logger);
static const wxString& GetTimestamp();
/**
Sets the timestamp format prepended by the default log targets to all
@@ -968,32 +882,36 @@ public:
static void DisableTimestamp();
/**
@deprecated
Sets the trace mask, see @ref log_tracemasks section for details.
Returns whether the verbose mode is currently active.
*/
static void SetTraceMask(wxTraceMask mask);
static bool GetVerbose();
/**
Activates or deactivates verbose mode in which the verbose messages are
logged as the normal ones instead of being silently dropped.
The verbose messages are the trace messages which are not disabled in the
release mode and are generated by wxLogVerbose().
@see @ref overview_log
*/
static void SetVerbose(bool verbose = true);
//@}
/**
Suspends the logging until Resume() is called.
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).
This function shows them all and clears the buffer contents.
If the buffer is already empty, nothing happens.
Note that the latter must be called the same number of times as the former
to undo it, i.e. if you call Suspend() twice you must call Resume() twice as well.
Note that suspending the logging means that the log sink won't be be flushed
periodically, it doesn't have any effect if the current log target does the
logging immediately without waiting for Flush() to be called (the standard
GUI log target only shows the log dialog when it is flushed, so Suspend()
works as expected with it).
@see Resume(), wxLogNull
If you override this method in a derived class, call the base class
version first, before doing anything else.
*/
static void Suspend();
virtual void Flush();
/**
Log the given record.