Visual Studio 2008 viewing dialog after breakpoint hit

Question

I am building a C++ MFC application that creates modal dialog boxes, one at a time, while hiding the parent dialog. I wish to view the newly created modal dialogs when a breakpoint is hit when debugging in Visual Studio. However, anytime a breakpoint is hit, the contents of the dialog box are no longer rendered. The box simply goes white, or retains whatever image is imposed on top of it. The dialog displays normally when the program is resumed, but I need to be able to view the dialog box when the breakpoint is hit, while the program is "paused" by the Visual Studio debugger.

Answer 1

You can't do this: to repaint the content of the dialog requires that the program be running. If it's stopped at a breakpoint, it's not running.

This is probably because you've got Visual Studio and your program sharing screen space, so that Visual Studio appears over your program. When you bring your program to the front, it needs to repaint (but can't because it's at a breakpoint).

The first thing that comes to mind is to get another monitor, and to make sure that Visual Studio and your program are running on separate monitors -- that way, your program won't need to repaint itself, and you should see what was previously on the dialog.

Alternatively, get two computers and remote debug from one to the other -- again, your program won't need to repaint itself, so you should still see what was there before.

Answer 2

There is one more thing you can do, temporarily put dialog.Invalidate(); dialog.SendMessage(WM_PAINT); after your breakpoint, make sure Visual Studio and the dialog are not overlapping, then step over the paint message. If the dialog is blanked it should fill.

There are a lot of gotchas with setting up Remote Debug, but once you get the hang of it, it's invaluable. It will definitely take care of your current situation, and once you have an environment ready you'll solve future bugs faster. Lots of times I've hit a problem and said, "if I only had a good remote debug environment I'd do A, but instead I'll try inferior solution B first..."