How does one isolate console I/O from graphics I/O?

[WSinc]

When composing a graphics program for my MATH students, I usually have to provide console I/O to read in parameters and for debugging, i.e. with READ *and PRINT * statements.

I find that that interferes with the graphics, unless there is a way to keep the console I/O in a separate window, and open the graphics windows separately.

Is there a way to accomplish that? If I open a graphics window, I have found that console I/Oafterward appears in that window. Clearly they should be isolated, since if one wishes to print the graphics out, you wouldn't want that to appear along with it.

How do I direct the graphics output to switch between windows, if I have more than one open at a time?

Thanks; Bill S.

[Steven_L_Intel1]

You're using QuickWin. As I pointed out in your other thread, you can open additional windows.

Use something like this:

open (unit=10,file='USER',title='My Window Title')

Now you can read and write "console" I/O from unit 10. You can change or ask about the focus using the routines FOCUSQQ, SETACTIVEQQ, GETACTIVEQQ and INQFOCUSQQ.

See the section of the on-disk documentation Building Applications > Using Windows Features > Using QuickWin for much more information.

[garylscott1]

Not quite what you asked, but a console window is just like any other window under the hood, so you can also write the graphics in the same window, or in a viewport/panel within the same (console) window, if you acquire the handle. I don't quite recall whether you can interact with a quickwin though; it might be a challenge unless you understand what's going on behind the scenes. However, a normal console window using the normal console (windows) API is straightforward.

[g_f_thomas]

Check these out:

http://wxmaxima.sourceforge.net/

http://downloads.sourceforge.net/gnuplot/gp422win32.zip?modtime=1188653679&big_mirror=0

Gerry

[Jugoslav_Dujic]

Not quite what you asked, but a console window is just like any other window under the hood, so you can also write the graphics in the same window... it might be a challenge unless you understand what's going on behind the scene

Quite the contrary -- a console window is decidedly not like "any other window under the hood", and it was deliberately made that way by the Windows designers. It does have some properties of a normal window, but lacks the most, starting from the window procedure. It's not even simple to take its handle. Console window handling is burried deep into system dll's. Making the graphics appear there is far more than just "a challenge" (and I don't see why would someone want to do that, anyway).

It's far easier the other way round -- to "emulate" the console window behavior from a GUI application. That's what QuickWin does, Matlab, wxMaxima as far as I can tell... the good ol' edit box already provides lots of features.