Welcome to our forums
Sorry for the delayed response on this item. I will try to take a look at it later today.
John - Many thanks for the thoughts. If I can identify the key areas where data listing is done, it could well be possible to use the Clearwin+ functionality for users to view the data, though the problem will still be there in the Clearwin transcript window which the user would want to keep as a record of the session. However, another option for that would be to echo everything to a print stream, assuming this wouldn't have the same problem (next thing for me to try out!).
Paul - thanks. That would be very helpful. I'm sure there must be a fairly simple solution to this!
-Steve
Steve,
You wrote : 'Clearwin transcript window which the user would want to keep as a record of the session' I do not know how to save the output window transcript. For me, once it closes it is lost. I write my trascript to another trace file ( that I open on unit 98, which I have used as a log unit for many years in many programs !)
Make sure that this 'Output' window is available to you.
You might also be interested in the way I close this window, as it can hang around. Then again we might be discussing different 'lazy' windows ?
subroutine close_output_window
!
INCLUDE <windows.ins>
!
integer*4 hwnd
logical L
!
hwnd = FindWindow('SalfordClass', 'Output')
write (98,*) hwnd,' = FindWindow('SalfordClass', 'Output')'
if (hwnd < 1) return
L = DestroyWindow (hwnd)
write (98,*) L, ' = DestroyWindow(hwnd)'
!
end subroutine close_output_window
John,
The embedded %cw window (in an earlier post) - which coincidentally is unit 99 - is straightforward Clearwin, so you can close it with an appropriate setting of the variable KONTROL (provided that is in a MODULE or COMMON). You can also send a message to a particular window to 'go and close itself' using SEND_TEXT_MESSAGE@ and also get a reply. It is also easily scrollable, up to some maximum length.
Once the stuff is sent to a display window, if you want to save it, you have to recapture it. My understanding is that you can cut'n'paste from such a %cw window, although FTN95.CHM is a bit vague on this, mentioning the standard callback COPY but not the others such as SELECT_ALL, and I've never done it. There may well be a lines limit too, although this appears to be user-selectable.
It is much easier to do a dual write: one to a file, and one to a window. The one thing you don't want is a 'PRINT NOW' button, as (of course depending what goes into a log file) they can get very long before you realise it!
Eddie
Good point, John .... in the old coding, there is in fact an 'ECHO' parameter. When set, this echoes everything that is written to the transcript to a 'printer' stream (actually to a file, together with the old carriagecontrol feature for page feed etc). I had hoped to avoid needing this by a simple 'select all' copy and paste from the CW window, but have just tried and found you can't do a select/copy operation on it. So I'll just have to make sure the echo functionality is preserved! By the way, I don't use the window close coding that you quoted - just a program 'stop' seems to close the winodw perfectly OK!
-Steve
Sometimes the text window sticks around if the program stops due to an error when you are developing a program. That inhibits a link step, and you need to kill off the hanging window with the task manager.
Having inserted the line:
IA=WINIO@('%ac[F1]&','COPY')
into my demo (previous posting) I discover that selecting the whole of '@Blimey!' by pressing F1 gives nothing to paste, but selecting just 'Blimey!' allows pasting of '@Blimey!', i.e. the '@' seems to come from nowhere. So @ clearly has some major significance! Also, putting an accelerator in with SELECT_ALL as its callback doesn't work.
Eddie
It turns out that ClearWin windows have an 'escape' character and the default 'escape' character is '@'.
If you are using %cw then %`cw provides a handle and the function set_win_escape@ can be used to change the default escape character to something else.
C_EXTERNAL SET_WIN_ESCAPE@ '__set_win_escape' (VAL,VAL)
i=winio@('%30.3`cw[hscroll,vscroll]&',10,cwh1)
i=winio@('%lw',ctrl)
call set_max_lines@(cwh1,50)
call set_win_escape@(cwh1, '\')
If you are just using Fortran PRINT etc in a Windows program then the simplest solution may be for me to provide a routine to enable you to set your own default escape character.
Paul - That's brilliant -- can use what you've posted (and can set up the CW window explicitly), or if you could write a little routine to do it that would be even better! Is this one that should usefully be added to the knowledgebase list?
By the way, you've also just generated a new FTN95 sale. Impressive support response! My old v3.0 licence needed updating.
Interesting -- I had a compiler problem with that C_EXTERNAL statememt so thought I'd look in the CHM file and the printed manual. And what did I find but SET_WIN_ESCAPE is listed as an obsolete Clearwin subroutine - but the printed manual gives instructions on how to call it. Compiled and linked OK, now just about to test ....
-Steve
Paul,
I knew you had the answer.
Perhaps we all should have consulted 'Clearwin+ Fortran Edition' dated June 1995 (page107, or page 103 where ADD_TEXT_DESCRIPTOR is described), where the use of <ESC_CHAR>tn to modify text characteristics is described. For the simple minded like me, the ESC_CHAR is not ESC (CHAR(27))! This looks like it is possible to set fonts, font characteristics (italic, bold etc) and colour on the fly in a Clearwin window...
This also requires ignoring the mention of SET_WIN_ESCAPE@ being obsolete (FTN95.CHM).
Paul, Do you want my copy of this manual? I had to brush cobwebs off it.
Eddie
Eddie, your copy of Clearwin+ Fortran Edition is even older than mine. My copy is dated 4th July 1997. However, mine has a note under SET_WIN_ESCAPE that it is a Clearwin 3.1 function that is obsolete in ClearWin+
I wonder how many other obsolete functions could usefully be revived? They could even be spun as 'new features' !
OK, just done the test. Unintended consequences. While the (obsolete) SET_WIN_ESCAPE clears the @-char problem, I now have a different problem elsewhere. I use the COUA@ subroutine to write out a prompt with suppression of the linefeed that normally follows a WRITE, so that user input goes on the same line. Unfortunately, this prompt now goes into another brand new Clearwin window that seems to be opened specially for it! Oh well, I'm sure I'll find another way around this one. It's all one big learning experience.
... 10 minutes later
Problem solved. Opening the lazy CW window with
iwin = Create_Window@ (....) i = Set_Default_Window@ (...) call Open_to_Window@ (lun,iwin)
iwin is the handle of the window created. All that is needed then is to add the obsolete function
call Set_Win_Escape (iwin1,'~')
to change the escape character from @ to ~
Job done.
many thanks, Paul, Eddie, John, and all!
Steve,
WIN_COUA (p96) has parameters of Window_handle, string, No_of_chars
Is this the one?
Eddie
Eddie -
Not WIN_COUA (p348 in my edition) but COUA@ (in FTN95.CHM) which takes only one argument, the character string to output. Yes, WIN_COUA would have done the job, as the window handle is one of the arguments. But not needed now (see 2 posts up) - just a call to SET_WIN_ESCAPE for the lazy window does the trick.
-Steve
The 'problem solved' section didn't say solved COUA@ !!
So I was just guessing.
However it looks to me that by judicious use of the Escape sequence to change font characteristics you could have prompts and answers in different font style &/or colour too ...
Eddie
I will add to the code for set_win_escape@ so that, when the first argument is zero, the second argument becomes the default escape character.
If you seriously can use the functionality of the escape character, perhaps someone could write a paragraph for me to put in the help file. If I ever knew what it does, I have forgotten.
Eddie - Now that would be interesting. But as my main priority is just to get the program running properly before doing fancy stuff with the graphics, I think that's an avenue I won't be exploring for a while! Thanks for all your help and encouragement. Things have come a long way since my first Fortran program in 1971 (and my first Algol-60 program in 1967). Though there's actually still some 1972-73 vintage code in the program I'm working on now.
Paul - seems that Eddie might know something of the functionality! As far as I was concerned (the reason for this thread) it was just a nuisance as there seemed no reason for the @ character to behave differently from others! However, I agree, it would be good to document it if there is functionality that nobody is using only because it's supposed to be obsolete.
Once you know what is possible, it isn't all that difficult. The following was produced with some assistance from that old Clearwin manual.
WINAPP
PROGRAM AT
COMMON / CLEARWIN_HANDLE/ iCW_Handle
INCLUDE <WINDOWS.INS>
INTEGER, EXTERNAL:: WRITEAT
IA = WINIO@('%ca[Test for embedded CW window]%2nl%pv'//
& '%70.30cw[vscroll,hscroll]%lc&',
& 99, iCW_Handle)
IA=WINIO@('%ww%sc&', WRITEAT)
IA=WINIO@('%ac[F1]&','COPY')
IA=WINIO@('%ff%nl%rj%12bt[STOP]'//
& '%lw', KONTROL)
STOP
END
INTEGER FUNCTION WRITEAT()
COMMON / CLEARWIN_HANDLE/ iCW_Handle
INCLUDE <WINDOWS.INS>
CALL GET_SYSTEM_FONT (LFHEIGHT, LFWIDTH, LFESCAPEMENT,
& LFORIENTATION, LFWEIGHT, LFITALIC,
& LFUNDERLINE, LFSTRIKEOUT, LFCHARSET,
& LFOUTPRECISION, LFCLIPPRECISION, LFQUALITY,
& LFPITCHANDFAMILY, LFFACENAME)
LFITALIC = 1
NEWFONT = CreateFont (LFHEIGHT, LFWIDTH, LFESCAPEMENT,
& LFORIENTATION, LFWEIGHT, LFITALIC,
& LFUNDERLINE, LFSTRIKEOUT, LFCHARSET,
& LFOUTPRECISION, LFCLIPPRECISION, LFQUALITY,
& LFPITCHANDFAMILY, LFFACENAME)
CALL ADD_TEXT_DESCRIPTOR (iCW_Handle, NEWFONT, RGB@(255,0,0))
LFITALIC = 0
LFUNDERLINE = 1
NEWFONT = CreateFont (LFHEIGHT, LFWIDTH, LFESCAPEMENT,
& LFORIENTATION, LFWEIGHT, LFITALIC,
& LFUNDERLINE, LFSTRIKEOUT, LFCHARSET,
& LFOUTPRECISION, LFCLIPPRECISION, LFQUALITY,
& LFPITCHANDFAMILY, LFFACENAME)
CALL ADD_TEXT_DESCRIPTOR (iCW_Handle, NEWFONT, RGB@(0,0,255))
WRITE(99,*) '@t1This is the default font - maybe for headings'
WRITE(99,*) '@t2This is the first additional font - red, italic'
WRITE(99,*) '@t3This is the next additional font - blue, upright'
& //', underlined'
WRITEAT = 1
RETURN
END
To Steve, I say that if you have 'conversational' prompted input in a CW window, colour is a terrific way of distinguishing prompt from reply.
To Paul, I say that there really is no substitute for something like the above, so it isn't really obsolete at all. It therefore deserves mention in the CHM file, and possibly in the Knowledgebase. I haven't a clue whether or not it works with TrueType fonts, and indeed, what possible settings there are for the 14 variables.
Eddie
Excellent, Eddie. I guess somebody must know how it works. Definitely worth proper documentation!
Back in 2009 Paul introduced an option to %cw i.e. %cw[local_font] that makes the %cw window use the currently defined font, i.e. uses current %fn and %ts, but this doesn't allow colour and style changes within the text.
E
Paul,
Here's my suggestion for what to put in FTN95.CHM (as requested):
In the section headed “Clearwin windows” Remove ADD_TEXT_DESCRIPTOR@ and SET_WIN_ESCAPE@ from the obsolete list. Add a section describing the %cw[local_font] option, i.e. if this option is chosen then the font currently selected using %fn and %ts is used as the default font for the %cw window. Add a section about using ADD_TEXT_DESCRIPTOR@ to define multiple fonts for a particular %cw window, and how they are selected with an ESCape sequence, @tn embedded in the output. Add a section explaining how to change the ESCape code from @ if that symbol is required in the output. Put the subroutine names in the library reference
Eddie