forums.silverfrost.com

rcsaumarez · Joined: 23 Mar 2008 Posts: 9 Location: Cambridge UK

I am using a graphics window, created with %gr, in a full screen naked mode for an instrumentation GUI. I cannot discover how to kill off the graphics screen when the program terminates. Ideally, I would like to kill it from the calling program. Anybody know how to do this?
Richard Saumarez

PaulLaidler · Posted: Mon Oct 27, 2008 4:56 pm Post subject:

I am not sure what you have in mind but %lw may be what you need.
The window can be closed by setting the associated control variable.
You will find the details in ftn95.chm.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

I'm not sure if I am discussing the same window, but when using %gr, an output window is also created when fortran I/O is directed to the screen.
I think this is called a clearwin window.

How can this window be closed by the program, when exiting the process and %gr window ?
We may need a window handle and use destroy_window@, but I am not clear on how to get the required handle.

Should set_all_max_lines@ or set_max_lines@ (w) be called, for this window ? ( as recommended in the clearwin windows help )
What is the default line length without this call ?
Is it possible to transfer the information in this window to a text file ?

In the past I have ignored (forgot) these problems, and found the process continue to run, until the output screen is closed.

Thanks John

PaulLaidler · Posted: Wed Oct 29, 2008 10:14 am Post subject:

There are a number of questions posed.
Here is one solution to one of the questions...

LitusSaxonicum · Posted: Wed Oct 29, 2008 7:35 pm Post subject:

Paul's example uses the default class name. You can give your graphics window (or indeed any window) its own class name using Clearwin's %nc. You can then send messages to that window to do things other than simply shut down.

Eddie

PaulLaidler · Posted: Wed Oct 29, 2008 9:00 pm Post subject:

Eddie is right in general but in this case the window in question is an old ClearWin window (for print output) and its class name probably cannot be changed.

LitusSaxonicum · Posted: Wed Oct 29, 2008 11:44 pm Post subject:

Paul,

There are two questions running here: John's and Richard's. In the case of Richard, who initiated the topic, he's got a window opened (I imagine) with a %ww[super_maximise] so that we only see the client area, which he's filled with graphics (rather like a computer game) and that can be given its own class name. Am I right that the class name refers to the window, not simply the graphics area?

On readingFTN95.chm, I also see that there's a standard callback 'super_maximise'.

I didn't know quite whether John was referring to a window that opens to display text when you send formatted output to (say) device 0 without explicitly opening it - which seems to be one usage of the phrase "Clearwin window" - or an area specifically set up for fortran formatted output using a %cw format code (another use of the phrase "Clearwin window"). In the case of the former, you can't give it a classname with %nc, but in the case of the latter, especially where %cw is embedded in a window with menus and buttons, you most certainly can.

John: I didn't understand what you meant when you wrote "but when using %gr, an output window is also created when fortran I/O is directed to the screen" - any chance of an example?

Eddie

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Paul,

Thanks for the example. It worked ! I can now install this in the exit routine of my other lazy programs.

Eddie,
The window I am refering to is the other window that opens when I use fortran output such as write (*,*) 'Hello' in a graphic program using a %gr window. I have found it more useful as a way of debugging and also providing supporting information while the graphics screen is being updated. It is easy to alt-tab between the windows to get information on the program running. If you do not do any fortran output to the screen, then this window does not open.

It's a lazy, but very effective way of providing an on-screen report of what is happening.
When the program exits, this window stayed open and the process remains running, at 100% cpu usage. The file buffers for other files that were not explicitly closed also were kept open.

It's been an annoying feature for years and now solved.

John

JohnHorspool · Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK

John,

I work in the same fashion as you, having a text output window for reporting program status in addition to the graphics window. But spent a little effort with %cw to specify a fortran unit number and %lw so that the window could be closed gracefully when the program exits, thus avoiding the problem of a hanging window when the graphics window is closed.

LitusSaxonicum · Posted: Fri Oct 31, 2008 10:23 am Post subject:

On reading FTN95.chm (again and again and again!) it is striking that 'COPY' is mentioned in respect of %cw, but 'PASTE' isn't. FTN95.chm refers to this control as being "read-only", which confuses me, as my Fortran "writes" to it.

I get the impression that the text contents of a %cw area aren't really meant to be editable. I've never attempted to extract a subset of %cw box contents, but have found that if the %cw box contains a few hundred lines, say, then it is easy to print that, or to extract the whole lot to a file, by re-running the write statements that created it (after changing the unit number).

I have found that keeping either an explicit Clearwin window (created with a %cw) or an implicit one (created by writing to device=*) interspersed with graphics updates causes the screen to flash as focus is passed from one window to the other and back again, and as a result (because I don't like the effect), I have tried to arrange for text to be displayed in a clearwin window in small enough amounts that re-writing it is easier than cut'n'paste.

It is easy enough to re-write some hundreds of lines to a file, and then launch (say) Notepad to edit it using START_PROCESS@ or START_PPROCESS@

Eddie

JohnHorspool · Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK

Hi Eddie,

I have an option for the user to have text appearing in the %cw to be simultaneously written to a text file as well, writing to the text file can be turned on or off, the text file can be closed and a new one started at any time.

However useful as this is when gathering 100’s or 1000’s of lines of information (which should really be done via text files anyway), it is not very convenient when dealing with small amounts of data (such as interrogating the xyz coordinates of a point on the graphics display), where most users would expect to be able to highlight and grab such data to instantly drop into another application via the clipboard, as is possible with most windows applications.

For a "windows look and feel" I think that it is essential to be able to do this.

cheers,
John

LitusSaxonicum · Posted: Fri Oct 31, 2008 4:26 pm Post subject:

John,

My mental model was picking up a number of lines to drop into a report.

If you are just picking up x,y,z coords, then I can't see why they need to be in a %cw area. Surely then you need to parse the string to recover the coords, with all the error handling if the user hasn't been careful. In such a case I would pop up a window containing the coords in individually editable %rf boxes, with a button that lets you harvest the whole set at once.

Eddie

JohnHorspool · Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK

Hi Eddie,

The problem is that I use %cw for all sorts of information reporting not just xyz coordinates, and I may wish to grab the coordinates for several points not just an individual one.

When I pass the mouse cursor over any entity in the graphics window, it gets highlighted, a right mouse click then brings up a pop up menu from which edit is an option, for a point this brings up a dialog window with the coordinates in %rf boxes, list is another option which writes data to %cw, perhaps I should add another option to place data in the clipboard.

However it would be nice if %cw could have properties like the quick edit mode of a DOS window, my code with copy and paste was my rather feeble attempt at doing this.

cheers,
John

LitusSaxonicum · Posted: Sat Nov 01, 2008 12:59 pm Post subject:

Hi John,

Isn't an %eb with the read_only attribute more likely to give you the functionality that you require than %cw? This might require the option "list for editing" (%eb) as well as "list".

I still have trouble with the idea of losing the underlying structure of the data by converting it to text, and then having to reconstruct the structure and values later from a sample of that text.

As for writing comparatively small amounts of data to and from disk files, this is lots faster than you would think because if the data set is accessed very quickly after it was written, then it still resides in the disk cache - indeed, it may not have actually been written to disk when you retrieve it! (You then don't need the clipboard!).

Eddie