I am trying to debug a graphics application.
However when I hit a breakpoint, the graphics window does not appear unless I position
the mouse onto the appropriate place on the taskbar. I have to click on that to make the graphics window appear.
When I try to scroll the graphics window, or resize it it disappears.
How can I make it STAY visible
so I can do somethingwith it?
There must be some magic trick, I just can't figure out what it it - - -
You can't. The graphics window is controlled by a thread that processes its messages - when you hit a breakpoint, the whole program stops, including any threads. If you try to do something to it, Windows sends it messages which never get handled, and that's not good.
It seems like a major hangup. Why can't they correct the situation?
For example ,make a copy of the graphics window when a breakpoint is hit.
The graphics window cannot repaint itself when the code to perform the repaint is not running (at break point).
The way to resolve this is to assure that the debugger (e.g. Visual Studio) and your app graphics window do not overlap.
IOW reduce the size of both VS (debugger) and app graphics window to fit on one screen...
or use dual monitor setup with VS on one monitor and your app graphics window on the other.
Jim Dempsey
BTW, this will not fix the scrolling of the graphics window (this requires your app to be running).
On the dual monitor setup, some display drivers permit you to have a virtual display that is larger than the physical display.
In such a setup, you can graph to the larger virtual display (seeing only a portion on the physical display) then at break point
The virtual display can be scrolled without interaction with the app (to repaint).
Jim Dempsey
However, even if you do what Jim suggests (and it is something I have done in the past), you will be able to see what was in the window before the breakpoint but not be able to "do anything with it". Any attempt to interact with that window (even to the extent of clicking in it) will result in Windows trying to send messages to the application that aren't processed, and Windows may decide your application is "not responding".
I don't have a dual display set up,
However, I could insert PAUSE or READ statements instead of using breakpoints.
That would allow the app to still be "running."
Maybe that's the best compromise.
Don't use PAUSE. READ might work, or calling MESSAGEBOXQQ.