Fix broken and missing DataView interface items for Phoenix

[wxWidgets.git] / docs / doxygen / overviews / log.h

diff --git a/docs/doxygen/overviews/log.h b/docs/doxygen/overviews/log.h
index fc474a41ca7900a3bc0dbc612b802718595fe0ba..ecd4f2b9f8141ad82c26e73f33477dd92a4906fb 100644 (file)
--- a/docs/doxygen/overviews/log.h
+++ b/docs/doxygen/overviews/log.h
@@ -8,30 +8,9 @@
 
 /**
 
 
 /**
 

-@page overview_log wxLog Classes Overview
+@page overview_log Logging 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
-
-@li @ref overview_log_introduction
-@li @ref overview_log_targets
-@li @ref overview_log_customize
-
-<hr>
-
-
-@section overview_log_introduction Introduction
+@tableofcontents

 
 This is a general overview of logging classes provided by wxWidgets. The word
 logging here has a broad sense, including all of the program output, not only
 
 This is a general overview of logging classes provided by wxWidgets. The word
 logging here has a broad sense, including all of the program output, not only


@@ -41,49 +20,50 @@ 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,
 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.
     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.
     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.
     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).
     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).
     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.
     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
     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.
     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).
     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.
     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
     this function takes a trace mask as the first argument which allows to
     further restrict the amount of messages generated.
 
     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
     this function takes a trace mask as the first argument which allows to
     further restrict the amount of messages generated.
 

+@see @ref group_funcmacro_log "Logging Functions and Macros"
+

 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
 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


@@ -120,6 +100,7 @@ classes are. Some of advantages in using wxWidgets log functions are:
     about data file writing error.
 
 
     about data file writing error.
 
 

+

 @section overview_log_enable Log Messages Selection
 
 By default, most log messages are enabled. In particular, this means that
 @section overview_log_enable Log Messages Selection
 
 By default, most log messages are enabled. In particular, this means that


@@ -150,24 +131,28 @@ you could give it the value "MyProgram" by default and re-define it as
 "MyProgram/DB" in the module working with the database and "MyProgram/DB/Trans"
 in its part managing the transactions. Then you could use
 wxLog::SetComponentLevel() in the following ways:
 "MyProgram/DB" in the module working with the database and "MyProgram/DB/Trans"
 in its part managing the transactions. Then you could use
 wxLog::SetComponentLevel() in the following ways:

-    @code
-        // disable all database error messages, everybody knows databases never
-        // fail anyhow
-        wxLog::SetComponentLevel("MyProgram/DB", wxLOG_FatalError);

 
 

-        // but enable tracing for the transactions as somehow our changes don't
-        // get committed sometimes
-        wxLog::SetComponentLevel("MyProgram/DB/Trans", wxLOG_Trace);
+@code
+// disable all database error messages, everybody knows databases never
+// fail anyhow
+wxLog::SetComponentLevel("MyProgram/DB", wxLOG_FatalError);
+
+// but enable tracing for the transactions as somehow our changes don't
+// get committed sometimes
+wxLog::SetComponentLevel("MyProgram/DB/Trans", wxLOG_Trace);
+
+// also enable tracing messages from wxWidgets dynamic module loading
+// mechanism
+wxLog::SetComponentLevel("wx/base/module", wxLOG_Trace);
+@endcode

 
 

-        // also enable tracing messages from wxWidgets dynamic module loading
-        // mechanism
-        wxLog::SetComponentLevel("wx/base/module", wxLOG_Trace);
-    @endcode

 Notice that the log level set explicitly for the transactions code overrides
 the log level of the parent component but that all other database code
 subcomponents inherit its setting by default and so won't generate any log
 messages at all.
 
 Notice that the log level set explicitly for the transactions code overrides
 the log level of the parent component but that all other database code
 subcomponents inherit its setting by default and so won't generate any log
 messages at all.
 

+
+

 @section overview_log_targets Log Targets
 
 After having enumerated all the functions which are normally used to log the
 @section overview_log_targets Log Targets
 
 After having enumerated all the functions which are normally used to log the


@@ -177,10 +162,11 @@ 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
 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
 
 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


@@ -193,7 +179,6 @@ formatting. Finally, it is enough to override wxLog::DoLogText() if you only
 want to redirect the log messages and the destination doesn't depend on the
 message log level.
 
 want to redirect the log messages and the destination doesn't depend on the
 message log level.
 

-

 There are some predefined classes deriving from wxLog and which might be
 helpful to see how you can create a new log target class and, of course, may
 also be used without any change. There are:
 There are some predefined classes deriving from wxLog and which might be
 helpful to see how you can create a new log target class and, of course, may
 also be used without any change. There are:


@@ -231,12 +216,35 @@ also be used without any change. There are:
     wxLogMessage("..."); // ok
     @endcode
 
     wxLogMessage("..."); // ok
     @endcode
 

+@see @ref group_class_logging "Logging Classes"
+

 The log targets can also be combined: for example you may wish to redirect the
 messages somewhere else (for example, to a log file) but also process them as
 normally. For this the wxLogChain, wxLogInterposer, and wxLogInterposerTemp can
 be used.
 
 
 The log targets can also be combined: for example you may wish to redirect the
 messages somewhere else (for example, to a log file) but also process them as
 normally. For this the wxLogChain, wxLogInterposer, and wxLogInterposerTemp can
 be used.
 
 

+
+@section overview_log_mt Logging in Multi-Threaded Applications
+
+Starting with wxWidgets 2.9.1, logging functions can be safely called from any
+thread. Messages logged from threads other than the main one will be buffered
+until wxLog::Flush() is called in the main thread (which usually happens during
+idle time, i.e. after processing all pending events) and will be really output
+only then. Notice that the default GUI logger already only output the messages
+when it is flushed, so by default messages from the other threads will be shown
+more or less at the same moment as usual. However if you define a custom log
+target, messages may be logged out of order, e.g. messages from the main thread
+with later timestamp may appear before messages with earlier timestamp logged
+from other threads. wxLog does however guarantee that messages logged by each
+thread will appear in order in which they were logged.
+
+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.
 @section overview_log_customize Logging Customization
 
 To completely change the logging behaviour you may define a custom log target.


@@ -247,7 +255,7 @@ 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
 
 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()
+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
 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


@@ -255,27 +263,66 @@ 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.
 
 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
+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().
+
+Additionally, you can customize the way full log messages are constructed from
+the components (such as time stamp, source file information, logging thread ID
+and so on). This task is performed by wxLogFormatter class so you need to
+derive a custom class from it and override its Format() method to build the log
+messages in desired way. Notice that if you just need to modify (or suppress)
+the time stamp display, overriding FormatTime() is enough.
+
+Finally, if even more control over the output format is needed, then
+DoLogRecord() can 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.
 
 
 customizing the dialog used by wxLogGui for the single messages.
 
 

-@section overview_log_mt Logging in Multi-Threaded Applications
+@section overview_log_tracemasks Using Trace Masks

 
 

-Starting with wxWidgets 2.9.1, logging functions can be safely called from any
-thread. Messages logged from threads other than the main one will be buffered
-until wxLog::Flush() is called in the main thread (which usually happens during
-idle time, i.e. after processing all pending events) and will be really output
-only then. Notice that the default GUI logger already only output the messages
-when it is flushed, so by default messages from the other threads will be shown
-more or less at the same moment as usual. However if you define a custom log
-target, messages may be logged out of order, e.g. messages from the main thread
-with later timestamp may appear before messages with earlier timestamp logged
-from other threads. wxLog does however guarantee that messages logged by each
-thread will appear in order in which they were logged.
+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.

 
 

-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).
+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.
+
+*/