How do I keep graphics window visible?

[billsinclaol_com]

I have a QUICKWIN app I am trying to debug, and it has utput generated by PRINT statements and graphics
routine calls.

The problem is: when I set a breakpoint the graphics window disappears.

Is there some trick to prevent this?

In other words, I would like to have both the graphics window and the debugging
capability available at the same time.

Any ideas? I'm kind of surprised that VS 2008 has this problem built in.

Is the problem cured by a later version?

[jimdempseyatthecove]

Dual monitors are your friend.
Run the VS IDE in one and (drag) your app window to the other.
If you only have one display (I suggest you get a second display) then make your IDE window sizable (button just left of in upper left corner), and, if necessary, make your graphics window sizable as well. Note,Alt-Enter usually will toggle between full screen and sizable screen.

Jim Dempsey

[Steven_L_Intel1]

The problem is common to any "windowing" application - as soon as the debugger takes control, the thread of the program that is handling Windows events stops executing. Therefore, if the graphic window is obscured by the VS window, it won't be able to repaint itself if you try to bring the window to the foreground.

If you can't use dual monitors, then try to arrange windows so that the VS window is not on top of your application window.

[WSinc]

Until I get two monitors (and the appropriate video card) I have to live with the
windows clash problem.

However, I do have a temp solution:
(1) Put PAUSE (or READ *,*) statements where you want the code to stop and
look at the app graphics.
(2) Insert a breakpoint at _FOR_PAUSE or whatever the appropriate routine is.

This allows you to look at debugging stuff, then if you want to see the graphics window
hit F5 or F10, and that puts focus back there. I admit it's kinda "klugey" but I found that
not making the two windows clash was a lot more trouble. The windows have to both be pretty large to
be useful.

BTW, even though PAUSE is supposed to be obsolete, it can give you more info
than READ(*,*) since you can put a character string after it, i.e.
PAUSE "subroutine SUB1 line 12"

[jimdempseyatthecove]

The PAUSE will work only if you can plan your breakpoints ahead of your debug session.

Here is an alternative "hack" (I haven't tried this with QuickWin)

Make your make both the IDE and QuickWin window sizeable.
"squish" down the IDE window such that it is practaly unusable (except for F5, F10, F11)
Set your QuickWin app window to a resonable size.

Click on the IDE window button to expand to full screen, look around etc...
Prior to continue, reduce the IDE window to its unusably small size, then F5, F10, F11...

At break, click on QuickWin window title bar, press Alt-Print-Screen
This should capture the current contents into clipboard
Open Paint
Paste clip board image into Paint
Expload IDE
Now Paint will refreash copy of QuickWin window as you check things out.
Leave Paint open for next step in debugging

Alternative (until you get 2nd display)
Some video adapters and/or Windows settings can be setup such that the Desktop area is larger than the monitor viewing area. To see all of the desktop you must pan the monitor viewing area. Using this technique (assuming you have this available) you should be able to have more resonable sized working windows (IDE and QuickWin).

Alternative-2
Setup your application for remote debugging. Then use your notebook or other PC to run the debugger (IOW now you have dual monitor).

Jim Dempsey