Debugging A WxWindow Application
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.
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.