another GetInt/GetId bug fix

[wxWidgets.git] / include / wx / debug.h

diff --git a/include/wx/debug.h b/include/wx/debug.h
index 99758d1f7a444a2c96d6b57fa6bc09f33844c9f6..4cb9dd165d94f1b1b171f0f21708317df8f30e4b 100644 (file)
--- a/include/wx/debug.h
+++ b/include/wx/debug.h
@@ -1,12 +1,12 @@
 /////////////////////////////////////////////////////////////////////////////
-// Name:        debug.h
+// Name:        wx/debug.h
 // Purpose:     Misc debug functions and macros
 // Author:      Vadim Zeitlin
 // Modified by:
 // Created:     29/01/98
 // RCS-ID:      $Id$
 // Copyright:   (c) 1998 Vadim Zeitlin <zeitlin@dptmaths.ens-cachan.fr>
-// Licence:    wxWindows license
+// Licence:     wxWindows license
 /////////////////////////////////////////////////////////////////////////////
 
 #ifndef   _WX_DEBUG_H_
@@ -14,24 +14,26 @@
 
 #include  <assert.h>
 
+#include  "wx/wxchar.h"
+
 // ----------------------------------------------------------------------------
-/** 
-  @name Debugging macros 
+/**
+  @name Debugging macros
 
   All debugging macros rely on ASSERT() which in turn calls user-defined
   OnAssert() function. To keep things simple, it's called even when the
   expression is TRUE (i.e. everything is ok) and by default does nothing: just
   returns the same value back. But if you redefine it to do something more sexy
-  (popping up a message box in your favourite GUI, sending you e-mail or 
+  (popping up a message box in your favourite GUI, sending you e-mail or
   whatever) it will affect all ASSERTs, FAILs and CHECKs in your code.
   <BR>
   <BR>
-  <b>Warning</b>: if you don't like advices on programming style, don't read 
+  <b>Warning</b>: if you don't like advices on programming style, don't read
   further! ;-)
   <BR>
   <BR>
   Extensive use of these macros is recommended! Remember that ASSERTs are
-  disabled in final (without WXDEBUG defined) build, so they add strictly
+  disabled in final (without __WXDEBUG__ defined) build, so they add strictly
   nothing to your program's code. On the other hand, CHECK macros do stay
   even in release builds, but in general are not much of a burden, while
   a judicious use of them might increase your program's stability.
@@ -41,6 +43,10 @@
 // ----------------------------------------------------------------------------
 //@{
 
+// Use of these suppresses compiler warnings about testing constant expression
+WXDLLEXPORT_DATA(extern const bool) wxTrue;
+WXDLLEXPORT_DATA(extern const bool) wxFalse;
+
 /** @name Macros which are completely disabled in 'release' mode */
 //@{
 #ifdef  __WXDEBUG__
@@ -51,34 +57,36 @@
   @param   szFile and nLine - file name and line number of the ASSERT
            szMsg            - optional message explaining the reason
   */
-  void WXDLLEXPORT wxOnAssert(const char *szFile, int nLine, const char *szMsg = (const char *) NULL);
+  void WXDLLEXPORT wxOnAssert(const wxChar *szFile, int nLine, const wxChar *szMsg = (const wxChar *) NULL);
 
   /// generic assert macro
-  #define   wxASSERT(cond)   if ( !(cond) ) wxOnAssert(__FILE__, __LINE__)
-  /// assert with additional message explaining it's cause 
-  #define   wxASSERT_MSG(x, m)  if ( !(x) ) wxOnAssert(__FILE__, __LINE__, m)
+  #define   wxASSERT(cond)   if ( !(cond) ) wxOnAssert(__TFILE__, __LINE__)
+
+  /// assert with additional message explaining it's cause
+  #define   wxASSERT_MSG(x, m)  if ( !(x) ) wxOnAssert(__TFILE__, __LINE__, m)
 #else
   // nothing to do in release modes (hopefully at this moment there are
   // no more bugs ;-)
   #define   wxASSERT(cond)
   #define   wxASSERT_MSG(x, m)
-#endif  //WXDEBUG
+#endif  //__WXDEBUG__
 
-  /// special form of assert: always triggers it (in debug mode)
+/// special form of assert: always triggers it (in debug mode)
 #define   wxFAIL                 wxASSERT(wxFalse)
-  /// FAIL with some message
+
+/// FAIL with some message
 #define   wxFAIL_MSG(msg)        wxASSERT_MSG(wxFalse, msg)
 //@}
 
 // NB: these macros work also in release mode!
 
-/** 
+/**
   These macros must be used only in invalid situation: for example, an
   invalid parameter (NULL pointer) is passed to a function. Instead of
   dereferencing it and causing core dump the function might try using
   CHECK( p != NULL ) or CHECK( p != NULL, return LogError("p is NULL!!") )
 
-  @name Macros which remain even in 'release' mode 
+  @name Macros which remain even in 'release' mode
 */
 //@{
   /// check that expression is true, "return" if not (also FAILs in debug mode)
@@ -100,4 +108,3 @@
 //@}
 
 #endif  // _WX_DEBUG_H_
-