How to prevent Print statements from interfering with graphics?

How to prevent Print statements from interfering with graphics?

I am working on a graphics APP, but I do from time to time have to insert Print statements, for user interaction,

informational purposes, and for debugging.

Despite my best efforts to keep the Print statements away from the graphics part, it corrupts the

graphics output. Of course we know that causing scrolling will destroy the graphics, but in this case no scrolling is involved.

The graphics are still corrupted. It would be nice to keep them in the same window, but maybe that really isn't practical.

 

So, if I open a separate window for the Print statements, how do I direct them to that window, and not the graphics window?

I guess the READ statements would also be in the same window, unless these is some kind of graphics interaction.

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You're using QuickWin. OPEN a new unit, let's call it unit 10, FILE='USER'. Rather than using PRINT, which goes to the initial output window, use WRITE (10,*).

Retired 12/31/2016

I treid that - 

I changed the PRINT statements to Write statements to LGU 10.

but there is still interaction between that and the graphics.

How do I put the WRITE statements in a SEPARATE window from the

graphics window? Do I have to open another window elsewhere?

 

When I say SETWINDOW, I don't see where I can assign a LGU

to that particular window. IS that discussed anywhere?

Did you open a new unit with FILE='USER' ? That would open a new subwindow.

Retired 12/31/2016

I was able to open two separate windows, but there still is a problem.

One covers the other. I was wondering if there is a way to have both

open, and visible at the same time.

I can shrink one down, but that makes it rather tricky,

trying to switch back and forth, shrinking one then the other.

A rather clumsy user interface.

In the menu bar, select Window > Tile.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today