Debugging GUI Applications in C++

Question

Background: I'm currently debugging an application written over a custom-built GUI framework in C++. I've managed to pin down most bugs, but the bugs I'm having the most trouble with tend to have a common theme. All of them seem to be to do with the screen refreshing, redrawing or updating to match provided data. This is a pain to debug, because I can't break on every refresh, and most of this stuff is time-sensitive, so breakpoints occasionally "fix" the bug.

Q: Does anyone have any tips for debugging Windows-based GUIs, especially regarding the refreshing of individual components?

Answer 1

This may not help, but I've found using dual monitors useful in this scenario. I have the debugger on one screen and the application on another. I can then step thru the code and see the application refreshing or doing whatever it is on the other screen. There is still issues with focus doing this way, but at least I can see when it repaints.

Answer 2

Having a dual screen really help when debugging refresh/redraw problem for Windows controls and UI.

Having the application on the second screen will not have the debugger generate "invalidate" on the main UI screens when it breaks for a debugging breakpoint.

If you cannot have a second screen, try to have both application side-by-side so that the application and the debugger will not interfere.

Answer 3

I agree with dual monitors or even remote debugging to reduce interfering with the messages.

I also highly recommend Spy utilities. These let you see what messages are being sent in the system. One such program is Winspector. http://www.windows-spy.com/

Answer 4

Logging is pretty much the only answer. Without knowing your framework I can't give an exact answer but basically open a file and append messages in the various procedures of interest. Finally close it.

In the message include the values of the variable that you are interested in.

Also using the window Message Box is useful to see if you are in the correct branch or procedure. This has minimal effect on over all flow.

Finally try downloading any of the express version of .NET and use Winforms to try to make test of particularly problematical areas. While Winform is it own framework there is a high degree of correspondence between it's control and the ones provided by Windows.

I maintain a simulation of the Project Mercury Capsule as an add-on for the Orbiter Space Simulator. It is written in C++ and has to use Win32 directly for some of the panels and dialogs. There were times I fired up VB6 (VB.NET later) to work out some complex interaction and then translated it over to it's Win32 equivalent in C++.

However this is a last resort.