Looking for comments on new functions and macros organization of Doxygen docs shown with this commit, see wx-dev.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@52438 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Bryan Petty
2008-03-11 07:57:21 +00:00
parent 2aee749cb1
commit c83e60aab5
8 changed files with 1253 additions and 1168 deletions

View File

@@ -6,165 +6,158 @@
// Licence: wxWindows license
/////////////////////////////////////////////////////////////////////////////
/**
/*!
@page page_macro_cat Macros by Category
@page page_macro_cat Macros by category
A classification of wxWidgets macros by category.
@li @ref page_macro_cat_version
@li @ref page_macro_cat_misc
@li @ref page_macro_cat_byteorder
@li @ref page_macro_cat_rtti
@li @ref page_macro_cat_debugging
@li @ref page_macro_cat_version
@li @ref page_macro_cat_byteorder
@li @ref page_macro_cat_rtti
@li @ref page_macro_cat_debugging
@li @ref page_macro_cat_misc
<hr>
<hr>
@section page_macro_cat_version Versioning
@section page_macro_cat_version Version macros
The following constants are defined in wxWidgets:
The following constants are defined in wxWidgets:
@li @c wxMAJOR_VERSION is the major version of wxWidgets
@li @c wxMINOR_VERSION is the minor version of wxWidgets
@li @c wxRELEASE_NUMBER is the release number
@li @c wxSUBRELEASE_NUMBER is the subrelease number which is @c 0
for all official releases
For example, the values or these constants for wxWidgets 2.8.7
are 2, 8, 7 and 0.
Additionally, @c wxVERSION_STRING is a user-readable string containing
the full wxWidgets version and @c wxVERSION_NUMBER is a combination of the
three version numbers above: for 2.1.15, it is 2115 and it is 2200 for
wxWidgets 2.2.
The subrelease number is only used for the sources in between official releases
and so normally is not useful.
@header{wx/version.h}
@header{wx/defs.h}
@li wxMAJOR_VERSION is the major version of wxWidgets
@li wxMINOR_VERSION is the minor version of wxWidgets
@li wxRELEASE_NUMBER is the release number
@li wxSUBRELEASE_NUMBER is the subrelease number which is @c 0 for all
official releases
@li wxCHECK_GCC_VERSION
@li wxCHECK_SUNCC_VERSION
@li wxCHECK_VERSION
@li wxCHECK_VERSION_FULL
@li wxCHECK_VISUALC_VERSION
@li wxCHECK_W32API_VERSION
For example, the values or these constants for wxWidgets 2.8.7
are 2, 8, 7 and 0.
Additionally, wxVERSION_STRING is a user-readable string containing the full
wxWidgets version and wxVERSION_NUMBER is a combination of the three version
numbers above: for 2.1.15, it is 2115 and it is 2200 for wxWidgets 2.2.
The subrelease number is only used for the sources in between official releases
and so normally is not useful.
@header{wx/version.h}
@header{wx/defs.h}
@li wxCHECK_GCC_VERSION
@li wxCHECK_SUNCC_VERSION
@li wxCHECK_VERSION
@li wxCHECK_VERSION_FULL
@li wxCHECK_VISUALC_VERSION
@li wxCHECK_W32API_VERSION
@section page_macro_cat_misc Miscellaneous macros
@section page_macro_cat_misc Miscellaneous
@header{FIXME}
@header{FIXME}
@li wxCONCAT
@li wxDECLARE_APP
@li wxDYNLIB_FUNCTION
@li wxDEPRECATED
@li wxDEPRECATED_BUT_USED_INTERNALLY
@li wxDEPRECATED_INLINE
@li wxEXPLICIT
@li wxON_BLOCK_EXIT
@li wxON_BLOCK_EXIT_OBJ
@li wxSTRINGIZE
@li wxSTRINGIZE_T
@li wxSUPPRESS_GCC_PRIVATE_DTOR_WARNING
@li __WXFUNCTION__
@li wxS
@li wxT
@li wxTRANSLATE
@li _
@li wxPLURAL
@li _T
@li WXTRACE
@li WXTRACELEVEL
@li wxCONCAT
@li wxDECLARE_APP
@li wxDYNLIB_FUNCTION
@li wxDEPRECATED
@li wxDEPRECATED_BUT_USED_INTERNALLY
@li wxDEPRECATED_INLINE
@li wxEXPLICIT
@li wxON_BLOCK_EXIT
@li wxON_BLOCK_EXIT_OBJ
@li wxSTRINGIZE
@li wxSTRINGIZE_T
@li wxSUPPRESS_GCC_PRIVATE_DTOR_WARNING
@li __WXFUNCTION__
@li wxS
@li wxT
@li wxTRANSLATE
@li _
@li wxPLURAL
@li _T
@li WXTRACE
@li WXTRACELEVEL
@section page_macro_cat_byteorder Byte order macros
@section page_macro_cat_byteorder Byte Order
@header{FIXME}
@header{FIXME}
The endian-ness issues (that is the difference between big-endian
and little-endian architectures) are important for the portable
programs working with the external binary data (for example, data
files or data coming from network) which is usually in some fixed,
platform-independent format.
The endian-ness issues (that is the difference between big-endian and
little-endian architectures) are important for the portable programs working
with the external binary data (for example, data files or data coming from
network) which is usually in some fixed, platform-independent format.
The macros are helpful for transforming the data to the correct format.
The macros are helpful for transforming the data to the correct format.
@li wxINTXX_SWAP_ALWAYS
@li wxINTXX_SWAP_ON_BE
@li wxINTXX_SWAP_ON_LE
@li wxFORCE_LINK_THIS_MODULE
@li wxFORCE_LINK_MODULE
@li wxIMPLEMENT_APP
@li wxINTXX_SWAP_ALWAYS
@li wxINTXX_SWAP_ON_BE
@li wxINTXX_SWAP_ON_LE
@li wxFORCE_LINK_THIS_MODULE
@li wxFORCE_LINK_MODULE
@li wxIMPLEMENT_APP
@section page_macro_cat_rtti RTTI macros
@section page_macro_cat_rtti Runtime Type Information (RTTI)
wxWidgets uses its own RTTI ("run-time type identification") system
which predates the current standard C++ RTTI and so is kept for backwards
compatibility reasons but also because it allows some things which the
standard RTTI doesn't directly support (such as creating a class from its name).
The standard C++ RTTI can be used in the user code without any problems and in
general you shouldn't need to use the functions and the macros in this section
unless you are thinking of modifying or adding any wxWidgets classes.
@sa
@ref overview_rtti
@li CLASSINFO
@li DECLARE_ABSTRACT_CLASS
@li DECLARE_APP
@li DECLARE_CLASS
@li DECLARE_DYNAMIC_CLASS
@li IMPLEMENT_ABSTRACT_CLASS
@li IMPLEMENT_ABSTRACT_CLASS2
@li IMPLEMENT_APP
@li IMPLEMENT_CLASS
@li IMPLEMENT_CLASS2
@li IMPLEMENT_DYNAMIC_CLASS
@li IMPLEMENT_DYNAMIC_CLASS2
@li wxConstCast
@li ::wxCreateDynamicObject
@li WXDEBUG_NEW
@li wxDynamicCast
@li wxDynamicCastThis
@li wxStaticCast
@li wx_const_cast
@li wx_reinterpret_cast
@li wx_static_cast
@li wx_truncate_cast
wxWidgets uses its own RTTI ("run-time type identification") system which
predates the current standard C++ RTTI and so is kept for backwards
compatibility reasons but also because it allows some things which the standard
RTTI doesn't directly support (such as creating a class from its name). The
standard C++ RTTI can be used in the user code without any problems and in
general you shouldn't need to use the functions and the macros in this section
unless you are thinking of modifying or adding any wxWidgets classes.
Related Overviews: @ref overview_rtti
@li #CLASSINFO
@li #DECLARE_ABSTRACT_CLASS
@li #DECLARE_APP
@li #DECLARE_CLASS
@li #DECLARE_DYNAMIC_CLASS
@li #IMPLEMENT_ABSTRACT_CLASS
@li #IMPLEMENT_ABSTRACT_CLASS2
@li #IMPLEMENT_APP
@li #IMPLEMENT_CLASS
@li #IMPLEMENT_CLASS2
@li #IMPLEMENT_DYNAMIC_CLASS
@li #IMPLEMENT_DYNAMIC_CLASS2
@li #wxConstCast
@li ::wxCreateDynamicObject
@li #WXDEBUG_NEW
@li #wxDynamicCast
@li #wxDynamicCastThis
@li #wxStaticCast
@li #wx_const_cast
@li #wx_reinterpret_cast
@li #wx_static_cast
@li #wx_truncate_cast
@section page_macro_cat_debugging Debugging macros
@section page_macro_cat_debugging Debugging
Useful macros and functions for error checking and defensive programming.
wxWidgets defines three families of the assert-like macros: the wxASSERT
and wxFAIL macros only do anything if __WXDEBUG__ is defined (in other words,
in the debug build) but disappear completely in the release build. On the other
hand, the wxCHECK macros stay event in release builds but a check failure doesn't
generate any user-visible effects then. Finally, the compile time assertions
don't happen during the run-time but result in the compilation error messages
if the condition they check fail.
Useful macros and functions for error checking and defensive programming.
wxWidgets defines three families of the assert-like macros: the wxASSERT and
wxFAIL macros only do anything if __WXDEBUG__ is defined (in other words, in
the debug build) but disappear completely in the release build. On the other
hand, the wxCHECK macros stay event in release builds but a check failure
doesn't generate any user-visible effects then. Finally, the compile time
assertions don't happen during the run-time but result in the compilation error
messages if the condition they check fail.
@header{wx/debug.h}
@header{wx/debug.h}
@li wxASSERT
@li wxASSERT_MIN_BITSIZE
@li wxASSERT_MSG
@li wxCOMPILE_TIME_ASSERT
@li wxCOMPILE_TIME_ASSERT2
@li wxFAIL
@li wxFAIL_MSG
@li wxCHECK
@li wxCHECK_MSG
@li wxCHECK_RET
@li wxCHECK2
@li wxCHECK2_MSG
@li wxASSERT
@li wxASSERT_MIN_BITSIZE
@li wxASSERT_MSG
@li wxCOMPILE_TIME_ASSERT
@li wxCOMPILE_TIME_ASSERT2
@li wxFAIL
@li wxFAIL_MSG
@li wxCHECK
@li wxCHECK_MSG
@li wxCHECK_RET
@li wxCHECK2
@li wxCHECK2_MSG
*/
*/