Debugging A WxWindow Application

From WxWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


If you compile with __WXDEBUG__ defined, your library and application will be more bloated but give much more diagnostic information. Note that either both the lib and the application should be compiled with __WXDEBUG__ or neither.


This function is used to generate debug output.

wxLogDebug(wxT("Something Happened"));

Tip: Under Windows, you must either run the program under debugger or use a 3rd party program such as DebugView to actually see the debug output.


It is good practice to use wxASSERTs in your source code to verify expected conditions. They are only active when __WXDEBUG__ is defined, however there is a potential problem. In a multi-threaded GUI application, a failing wxASSERT in a worker thread will generate a pop-up dialog box to tell you of the condition. Often instead of the pop-up window you will get an error from the underlying X11/Xlib libraries about asynchronous window events. This means that the reason for the original wxASSERT is lost, and you can spend a long time trying to track down the wrong bug. The solution to this is to define your own handler for wxASSERT events that does not make use of pop-up dialogs. Use the logging facilities and redirect the wxASSERT output to the log instead. This is done by overriding the OnAssert() method in wxApp. Here you have access to the name and line number of the wxASSERT that failed along with the text of the condition and an optional message.

External links

Debugging overview

Debugging macros and functions

wxLog classes overview

Log functions