How best to isolate console output from graphics?

How best to isolate console output from graphics?

I am trying to debug a graphics app but there is a lot of console output

involved for the computations being done. There are also READ statements which

solicit input quantities.


The problem is - the WRITE statements (or PRINT) causes a lot of scrolling,

which destroys the graphics output. How can I prevent that?

For example can I put the WRITE statements in a separate window?

Can I assign for example, assign a LOGICAL unit that would associate those WRITE statements

with a different window? Or is there a way to do WRAP AROUND of WRITE statements wthout any scrolling?

Ideally I would be able to scroll the WRITE outputs without affecting the graphics, but I don't know if that is possible

with the current software.

Any suggestions?


BTW, a good enhancement would be to enable opening a separate CONSOLE window from a GRAPHICS window, each

one having its particular characterisitics. The CONSOLE window would allow scrolling of text. That would solve this problem.

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

I assume this is a QuickWin app. You can open a separate unit with FILE='USER' and use that for your text output. This will go to a separate window within the QuickWin MDI interface.

Retired 12/31/2016

I tried that, but it was a confused mess.
when i did
it did open a window called UNIT7, but then all the graphics stuff went into there also.
I want the graphics to go into a DIFFERENTwindow so they don't screw each other up.

So do I have to keep SWITCHING them back and forth?
That seems pretty awkward and clumsy programming.

Ah, I see I forgot something. You have to call SETACTIVEQQ to unit 6 to cause the graphics to go to the default window. I think your WRITEs to unit 7 will separate automatically. I'm not super-familiar with this part of QuickWin so I suggest studying the documentation and looking at the various QuickWin routines available.

Retired 12/31/2016

Would the regular graphics windows rather than QuickWin be easier to implement this way?
Are there any articles about this?

BTW, does the new Fortran edition come with the repaired debugging environment
we talked about in a previous post?
Where it was giving exceptions, and cryptic error messages when modifying source code - - -
I looked at the release notes, did not find any mention of it.

Many issues were fixed in the development environment in Update 1. Please try it. The release notes don't tend to describe fixes - there is a separate "README" file posted with the downloads that has those.

I doubt you would find using the Windows API for graphics easier than QuickWin, and it would not allow you to do Fortran I/O to a window.

Retired 12/31/2016

Leave a Comment

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