This class represents a background log window: to be precise, it collects all
log messages in the log frame which it manages but also passes them on to the
- log target which was active at the moment of its creation. This allows, for
+ log target which was active at the moment of its creation. This allows you, for
example, to show all the log messages in a frame but still continue to process
them normally by showing the standard log dialog.
@class wxLogChain
@wxheader{log.h}
- This simple class allows to chain log sinks, that is to install a new sink but
+ This simple class allows you to chain log sinks, that is to install a new sink but
keep passing log messages to the old one instead of replacing it completely as
wxLog::SetActiveTarget does.
/**
Sets another log target to use (may be @NULL). The log target specified
- in the @ref ctor() constructor or in a previous call to
+ in the wxLogChain(wxLog*) constructor or in a previous call to
this function is deleted.
This doesn't change the old log target value (the one the messages are
forwarded to) which still remains the same as was active when wxLogChain
method.
@library{wxbase}
- @category{FIXME}
+ @category{logging}
*/
class wxLogBuffer : public wxLog
{
@wxheader{log.h}
wxLog class defines the interface for the @e log targets used by wxWidgets
- logging functions as explained in the @ref overview_wxlogoverview "wxLog
- overview".
+ 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
Otherwise, it is completely hidden behind the @e wxLogXXX() functions and
you may not even know about its existence.
- See @ref overview_wxlogoverview "log overview" for the descriptions of wxWidgets
- logging facilities.
-
@section overview_wxLog_deriving Deriving your own log target
There are two functions which must be implemented by any derived class to
@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 of being a matter of
+ 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
wxLog::AddTraceMask( wxTRACE_OleCalls);
@endcode
- Using string masks is simpler and allows to easily add custom ones, so this is
+ Using string masks is simpler and allows you to easily add custom ones, so this is
the preferred way of working with trace messages. The integer trace mask is
kept for compatibility and for additional (but very rarely needed) flexibility
only.
@library{wxcore}
@category{logging}
- @see wxLog::RemoveTraceMask, wxLog::GetTraceMasks
+ @see @ref overview_log
*/
class wxLog
{
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
+ which allows you 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
@class wxLogNull
@wxheader{log.h}
- This class allows to temporarily suspend logging. All calls to the log
+ This class allows you to temporarily suspend logging. All calls to the log
functions during the life time of an object of this class are just ignored.
In particular, it can be used to suppress the log messages given by wxWidgets