How to isolate console output from graphics?

[WSinc]

Hello -

When I am debugging a graphics program, I very often have to put WRITE statements
in. The problem is that it causes scrolling, which destroys the graphics.

Is there a way to set it up so that WRITE statements do not occupy the graphics windows?

Another (but less desirable) approach is to disable the scrolling, in other words "wrap around" output from the WRITE statements.

Of course, once the debugging is completed the WRITE statements can be commented out.

Actually, user interaction should be isolated from the graphics anyway, even
after the program has been debugged.

Any ideas? I think the problem is : you have to speciafy a CONSOLE application, or a GRAPHICS but
you can't specify "MIXED"

[Jugoslav_Dujic]

I don't think there is a legitimate solution. The catch is, when you link with QuickWin libraries (/libs:qwin), you automatically get the "graphic" version of WRITE. Maybe there is a hack with /IGNORE linker switch (so that you don't import QuickWin write), but then, I don't see what you would substitute it with.

I think the simplest solution is to write your version of WRITE, called e.g. MyWrite, used for debugging, and then put that output to the console using AllocConsole and WriteFile/WriteFile APIs (I think they both work, and have the same semantics). The catch it that it cannot really have variable number and type of arguments, like Fortran WRITE does. If you're interested, I have a routine which mimics the variable arguments semantics (though not in the identical fashion as WRITE). Alternatively, you can use internal write to a string, and then send that string to the console output.

[anthonyrichards]

QuickWin allows you to open other windows that you can use for text output. Just do that. This is an excerpt from th QUickWin part of the Compaq Visual Fortran Programmers guide:
"

The FILE='USER' option in the OPEN statement opens a child window. The child window defaults to a scrollable text window, 30 rows by 80 columns. You can open up to 40 child windows.

Running a QuickWin application displays the frame window, but not the child window. You must call SETWINDOWCONFIG or execute an I/O statement or a graphics statement to display the child window. The window receives output by its unit number, as in:

  OPEN (UNIT= 12, FILE= 'USER', TITLE= 'Product Matrix')
  WRITE (12, *) 'Enter matrix type: '

Child windows opened with FILE='USER' must be opened as sequential-access formatted files (the default). Other file specifications (direct-access, binary, or unformatted) result in run-time errors."

There then follows examples.

[levicki]

If you are working on Windows platform, in my opinion the best way to handle debug output is to use OutputDebugString() API and a tool such as DebugView. I am giving an example in C, but I suppose that linking it to the Fortran code shouldn't be a problem.

Trace.c:

[cpp]#include "Trace.h"

void __cdecl Trace(LPCTSTR format, ...)
{
	TCHAR buffer[1024];

	va_list arglist;
	va_start(arglist, format);
	_vsntprintf(buffer, sizeof(buffer), format, arglist);
	va_end(arglist);

	OutputDebugString(buffer);
}
[/cpp]

Trace.h:

[bash]#pragma once

#include 

void __cdecl Trace(LPCTSTR format, ...);
[/bash]

You can probably also use OutputDebugString() directly from Fortran -- perhaps someone else could provide you with the details for that because my Fortran skills are pretty rusty nowadays.

[WSinc]

This looks like the cleanest solution......

It does involve changing all the PRINT statements, but that can probably done fairly quickly.

But does that allow me to see both windows simultaneously?

Is there a way to download the user's manual to a PDF file I can search, and maybe print out the relevant pages?

[Steven_L_Intel1]

Either Anthony or Igor's solution will work. Anthony's has the advantage that the new window will show up inside the QuickWin MDI (Multiple Document Interface). With either, the "console" window will be a separate window you can move aside, shrink, etc.

You can print sections from within the documentation. It is not available as PDF. You can search the documentation.

[WSinc]

I tried that option file="user" and called the window "console" with a unit number of 12.
So, it worked OK with the write(12,*) etc statements. But now the graphics stuff is going into
that window also.

In other words, when I call the graphics stuff, I want it to be in another window, so it
would be nice to have a UNIT number for that. Otherwise I cant use the SETACTIVEQQ routine.

It opens a graphics window by default and calls it graphic1. But so far, I don't see how to assign a UNIT number to that. As I said above, the graphics stuff is not going into that window. Is there a way to open the graphics window with its own unit number and special name?

[WSinc]

Here is a simple program that illustrates the problem:

The circle is drawn in the console window, not in a separate graphics window like I wanted.
The SETWINDOW command has no way to tell the program which unit it refers to.
I think it's pretty obvious:
We need to have TWO types of windows, a console and graphics type.
Commands such as MOVETO and DRAWTO would would go intographics windows, while
WRITE and READ statements, or PRINT should go to the console windows.

The graphics windows could have negative unit numbers, for referencing with a
SETACTIVEQQ command. Otherwise there is no way to tell one from the other,or switch between them.

The current scheme does not return the unit number of any graphics window.
Do graphics windows even HAVE a unit number? How do you find out what it is?

The starting window (when execution is begun) should be a console type, with a unit number of zero.

When I was programming at JPL. we actually did have mixed window types.

[anthonyrichards]

You just have to kep track of your child windows (their unit numbers) and use FOCUSQQ to chose the childwindow that you want particular output to go to at a particular time. So probably best to use global variables held in a module that you can USE wherever you want access to the unit numbers. The first child window opened in quickwin is probably unit 6. Look at the RESIZE quickwin example but play with it a bit, for example add the following:

character(3) cwindo

windno = 6


1 CONTINUE
windno=windno+1
write(cwindo,'(i3)') windno
windname = 'TEST WINDOW '//cwindo//char(0)

OPEN (windno,FILE='USER')

This will add a new child window each time with a slightly different window title. In order to address a particular window, you would need to save 'windno' in a unique global variable (or possibly array?) IUNIT(i)=windno, then use FOSUSQQ(IUNIT(j)) to focus on a particular window for graphics output.

[WSinc]

Sorry, but I still could NOT get the graphics to go into another window.

Even when I opened another unit (13) and set SETACTIVEQQ(13),
the circle still went into the unit 12 window when I drew it.

I get the impression that the graphics calls are not associated withANY unit
numbers.

Please see modified test file.

[anthonyrichards · Accepted solution]

Have you not tried FOCUSQQ as I recommended?
If you were to modify the RESIZE quickwin example with the code below, which uses FOCUSQQ(7) to ALWAYS draw the graphic in window 7, you will find that a new, slightly shifted ellipse is always drawn in window unit=7, after which FOCUSQQ(windno) sets the focus to the latest USER window for text ouput, whatever the unit number of the latest opened window.
(n.b. the following is assumed to be FIXED FORMAT, continuation in column 6)

CHARACTER windname*20, cunit*3
windno = 6
windname = 'TEST WINDOW'C

1 CONTINUE
windno=windno+1
write(cunit,'(i3)') windno
windname = 'TEST WINDOW '//cunit//char(0)

OPEN (windno,FILE='USER')
result=FOCUSQQ(7)
result = ELLIPSE ($GFILLINTERIOR , 20*windno, 20*windno,
6 60+20*windno,60+20*windno)
result=FOCUSQQ(WINDNO)

[WSinc]

Well, not yet, but the issue seems to be more associated with putting the graphics in the proper
window, rather than where the focus is.

My understanding is that the FOCUSQQ routine is related to which window is in the foreground. You can still put graphics in a window that does not have current focus. I looked at the writeup, and it said that
FOCUS is automatically invoked when you do I/O unless you specify otherwise in the OPEN call.

For example, when you use the OPEN STATEMENT, it says you can
set IOFOCUS to FALSE when you don't want focus to automatically
occur when you do I/O to that file.

So you can write output to a window without causing it to have focus
automatically. The problem is that graphics output calls don't give you that kind of
flexibility.

Like I said before, it isn't clear that graphics windows have any way to reference them by a unit mumber.
When I invoked the routine to supply me with a unit number, it only returned the console window unit number.

So, I have no way to reference the graphics window, with a SETFOCUS or otherwise.

I will give it a go when I get home, though.

[WSinc]

See previous.

[anthonyrichards]

Clearly, it is the QuickWin programmer's responsibility to identify which unit's window is the required 'graphics' window. The graphics routines just draw to whichever window has been given focus using FOCUSQQ. I think that my demonstration shows that. Thus if you want all text output to go to a particular window, then you need to precede the code that generates your WRITE statements with a FOCUSQQ to the 'text' window and follow it with a FOCUSQQ to the graphics window to return all QuickWin output to the 'graphics' window by default.

This must be a consequence of the QUickWin design that permits both text and graphics output to the same window. And this is a consequence of a Quickwin window being a bitmap that is drawn on - your text is eventually drawn using graphics routines I believe, not just your lines and circles. To delete 'text', you have to undraw it. Thus each QuickWin window is both 'Text' and a 'Graphics'-capable, as you have discovered. The distinction is thus artificial.

[WSinc]

OK, I will try that one.

I think I not only have to set FOCUS, but set ACTIVE as well.

I will see if that works, anyway.

Thanks; Bill S.

[anthonyrichards]

Well, the modified RESIZE code, that uses FOCUSQQ only to redirect output, sends graphics to the correct window, even when the next newly opened user window has just been 'opened' and is on top and expecting input, which must mark it as the 'Active window'.