wxVector<T> is header-based, use @nolibrary

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

diff --git a/docs/doxygen/overviews/debugging.h b/docs/doxygen/overviews/debugging.h
index 948b4a5be0390f934f1fb5ef29a6cd51b0d8376e..c01da04628eb8846a9cd2aeac1611143c032a014 100644 (file)
--- a/docs/doxygen/overviews/debugging.h
+++ b/docs/doxygen/overviews/debugging.h
@@ -6,12 +6,12 @@
 // Licence:     wxWindows license
 /////////////////////////////////////////////////////////////////////////////
 
-/*!
+/**
 
- @page overview_debugging Debugging overview
+ @page overview_debugging Debugging
 
  Classes, functions and macros: wxDebugContext, wxObject, wxLog,
-                                @ref overview_logfunctions, @ref overview_debugmacros
+                                @ref page_func_cat_log, @ref page_macro_cat_debugging
 
  Various classes, functions and macros are provided in wxWidgets to help you debug
  your application. Most of these are only available if you compile both wxWidgets,
@@ -19,12 +19,19 @@
  defined. You can also test the __WXDEBUG__ symbol in your own applications to execute
  code that should be active only in debug mode.
 
+ @li @ref overview_debugging_dbgctx
+ @li @ref overview_debugging_dbgmacros
+ @li @ref overview_debugging_logging
+ @li @ref overview_debugging_dbgctx2
+
+
+ <hr>
 
 
  @section overview_debugging_dbgctx wxDebugContext
 
  wxDebugContext is a class that never gets instantiated, but ties together
- various static functions and variables. It allows you to dump all objects to that stream, 
+ various static functions and variables. It allows you to dump all objects to that stream,
  write statistics about object allocation, and check memory for errors.
 
  It is good practice to define a wxObject::Dump member function for each class you derive
@@ -40,9 +47,9 @@
  and compiler -- some systems don't allow all memory logging to be enabled). See the
  memcheck sample for example of usage.
 
- For wxDebugContext to do its work, the @e new and @e delete operators for wxObject 
- have been redefined to store extra information about dynamically allocated objects 
- (but not statically declared objects). 
+ For wxDebugContext to do its work, the @e new and @e delete operators for wxObject
+ have been redefined to store extra information about dynamically allocated objects
+ (but not statically declared objects).
 
  This slows down a debugging version of an application, but can
  find difficult-to-detect memory leaks (objects are not
@@ -57,7 +64,7 @@
  @endcode
 
  All occurrences of 'new' in wxWidgets and your own application will use
- the overridden form of the operator with two extra arguments. This means that 
+ the overridden form of the operator with two extra arguments. This means that
  the debugging output (and error messages reporting memory problems) will tell you what
  file and on what line you allocated the object. Unfortunately not all
  compilers allow this definition to work properly, but most do.
@@ -66,8 +73,9 @@
 
  @section overview_debugging_dbgmacros Debug macros
 
- You should also use @ref debugmacros_overview as part of a 'defensive programming' strategy,
- scattering wxASSERTs liberally to test for problems in your code as early as possible.
+ You should also use @ref page_macro_cat_debugging as part of a 'defensive programming'
+ strategy, scattering wxASSERTs liberally to test for problems in your code as early as
+ possible.
  Forward thinking will save a surprising amount of time in the long run.
 
  #wxASSERT is used to pop up an error message box when a condition
@@ -90,7 +98,7 @@
 
  @section overview_debugging_logging Logging functions
 
- You can use the #wxLogDebug and #wxLogTrace functions to output debugging information in 
+ You can use the wxLogDebug and wxLogTrace functions to output debugging information in
  debug mode; it will do nothing for non-debugging code.