forums.silverfrost.com

[silicondale]

I need to use @, the 'at' character, as a prefix to certain data that I am using. However, keyboard entry and screen display doesn't seem to work. Maybe this is documented somewhere, but I can't find it.

A simple program demonstrates the problem:

program testchars
character*1 testch

write (*,*) 'this should display four at chars @@@@'
write (*,*) 'please input char @'
read (*,*) testch
write (*,*) 'character entered=',testch

pause
stop
end

It displays two @ characters to start with, not the four supplied in the write statement.
The second write doesn't display any.
The keyboard read followed by write also doesn't display any.

Is there some simple solution such as a compiler switch to allow @ to be handled just like any other character? I don't see any similar problem with other special characters like & or * or %
_________________
(Steve Henley)

[PaulLaidler]

Maybe you can use char(v) and Fortran character concatenation (//) but keyboards and displays do vary.

[JohnCampbell]

I tried your program in a cmd.exe command box and found no problems.
I changed your program to test if * format was a problem, but I could not reproduce your problem.
However, if you compile with /win option then the problem occurs as you have described, but in the "output" window that opens when /win is selected.
I do recall reading somewhere how to overcome this problem, but I can't recall the solution. I think that @@ becomes a single @, but @x becomes nothing ?
@ is a special character in a graphics or clearwin+ output window.

[silicondale]

John - many thanks for the help. Indeed it does seem that the /WIN compiler option is the culprit.

However, as I really need to run the application in a Clearwin window rather than a DOS-style command window, it seems I have to use /WIN.

Indeed a double @@ is needed to display a single @ but it seems more complex than this, as even keying @@ isn't recognised as an @ by the program. It's a prefix used in the application to specify parameters, so it appears in lots of places in the code.

Although it's a 'legacy' program, I have new bolt-on developments which will need all the power of Clearwin+, and the starting point will be a Clearwin window for the I/O transcript. It's not clear to me why the @ character should be a special character at runtime. Anyway, a couple of options I can still try... compile the screen i/o subroutines without the /WIN, or (brute force option) globally replace @ by some other character such as the tilde ~ as the parameter prefix.
_________________
(Steve Henley)

[LitusSaxonicum]

I followed this with interest: it may be something lurking in Windows itself that is the problem. Sometimes you find such things by looking back at a Windows 1.0 manual!

You might get over it by having a check box for 'program parameter' as well as the text box and attach that to an accelerator key so that something like Alt-@ or Ctrl-@ inserts the @ symbol for you. (And no, I haven't tried it, sorry). This does rather assume that you are asking for input via a dialog box, and not via simply typing in response to prompts in a 'glass teletype' mode.

Eddie

[silicondale]

Hi, LS -

I think the problem will go away once I start using dialog boxes. Trouble is, the first step is to get my flat-screen teletype version working. It's a large and complex MSDOS application (with origins further back, in CP/M micros, and before that VAX and IBM360 implementations).

Squeezing the whole thing into CP/M machines with their 64K addressing limit was fun - setting up dozens of overlays, and chaining one part of the system to another when they were separable. Also coding a subsytem to handle virtual arrays to get arround the addressing problem. Those were the days! However, the legacy of those days is complex I/O buffering, the redundant virtual array code, etc.

I now just want to get the program running on Windows with a simple Clearwin (not Clearwin+) window. Then progressively cut out the garbage and add in some new graphics stuff that I've already tried out stand-alone, and replace the command/parameter interface by dialog boxes, so the problem of these single-character prefixes will fall away. So if I can get around it for now, that's good enough.
_________________
(Steve Henley)

[silicondale]

I have done some more testing. Using the Clearwin window and normal Fortran READ and WRITE statements.

(1) The READ from keyboard correctly inputs a string that contains the @ character, and stores it correctly. However, the echo back to the Clearwin window omits the @ and whatever character follows it.

(2) Any WRITE statement on any string containing @ omits both the @ character and any character that follows it.

(3) Entering two @ characters together @@ will echo one of them on READ from keyboard, and a WRITE on any character string containing @@ will display one of them.

(4) Trying to write out a single @ character outputs nothing at all.

I have gone through all the documentation I can find, and have seen no reference either to this behaviour or how to prevent it.

Can someone please help! All I want to do is to make @ behave like any other character such as % or $ or * or # all of which work properly.

This is not a keyboard-specific problem because it happens also from strings stored in the program using a DATA statement for example. It is a problem specifically related to output to the Clearwin window.
_________________
(Steve Henley)

[LitusSaxonicum]

Perhaps our only hope is Paul.

Here's a guess: The @ symbol means something in C, and Clearwin is written in C, so this is an inadvertent side effect of that.

Eddie

[silicondale]

Hi, Eddie - Sounds a good educated guess. However, there are plenty of special characters that have meaning within programming languages, but this shouldn't mean that their use within data has to be restricted. That's just bad design. For example, the ! character in FTN95 (or the C in older Fortrans) indicates a comment, but you can use them quite freely within any data processed by Fortran programs.

-Steve
_________________
(Steve Henley)

[LitusSaxonicum]

Steve,

That wasn't quite what I meant. Fortran doesn't have @ in its official character set (which is why it features so heavily in FTN95) - and why Paul had to replace it with $ in his 64-bit Clearwin. So, it has no meaning in generic Fortran. Then, its use in data is just bound by any other character not in the official character set.

But, as Clearwin (and maybe Windows itself?) is written in C and compiled with Salford C++ (scc.exe) then anything passed to it is interpreted according to the C++ rules. Hence I am not surprised that there are such glitches in using Clearwin - what perhaps surprises me is that they are so rare. What would surprise me is if a non-Clearwin program exhibited the behaviour you mention. However, it does not. For example:

[jalih]

How about simply using ClearWin window just for output? Use scrollbars with ClearWin window and put separate input box for commands right below it. You can add button with a callback for accepting the command, make it default button and then just pressing the enter key works too.

I can write you a small sample, if needed...

[silicondale]

Thanks for the further explanation, Eddie. All that I meant was that char(64) should be treated like char(anything else) when it is part of a set of data. I do indeed understand that within program code it has special significance in C, C++, Romulan, etc.- but this is not program code. It's simply a data stream.

The program, whatever language it's written in, shouldn't be second-guessing the user's intentions, and if it does something strange with particular data then this really should be highlighted in user documentation, not buried somewhere. It looks as though @ is being treated as some sort of escape character, and this also worries me - what if a two character combination (@-something) actually has some undocumented significance which causes a program action that the user is unaware of?

It's bad enough in my case where I am using @ as a special prefix for a particular class of data items (user parameter names). At least I know where it is being used. But it would be far worse for a user writing, for example, a text-processing application, where any occurrence of the @ character would not be displayed, nor the character immediately following it - and the user might or might not notice the problem immediately. If it were a really strange character I might understand, but it isn't - it's ASCII character 64.

There has to be a solution to this problem - or if not, then it has to be documented somewhere. As you say, FTN95.CHM is too brief. I have old copies of the hardcopy manuals - which contain more than is in the CHM file, but nothing about this problem in them, either.

-Steve
_________________
(Steve Henley)

[silicondale]

jalih -

Thanks for the suggestion, but I'm afraid it doesn't help, as it IS output that is the problem. The data input works fine apart from the echo, i.e. the @ and the following character are stored exactly as keyed in, but output of any string containing the @ character to a Clearwin window exhibits the problem.

-Steve
_________________
(Steve Henley)

[jalih]

[silicondale]

Many thanks for the sample coding, Jalih. It would solve the specific problem where I have an @ prefix to a parameter where I am inputting commands. If that were the extent of the problem, what you have suggested would be a good fix.

However, as my tests showed, the real problem is with output of any string containing the '@' character. It may not even be connected directly to the input but could be data read from a database, or a user's data file, or may even be a string produced as the result of computation within the program.

So this is not in general going to be just in this one place, but could be anywhere that text strings which could potentially contain '@' are written to the display. It is simply not practical to replace every write statement in the program by a call to an output buffer handler that replaces any occurrence of '@' by '@@' If it were just in the one place (a parameter input prefix) a much simpler solution would just be to use a different character such as '~' which doesn't have the problem.

What is needed is a general way to stop @ being treated differently from any other character in data strings. Either it's a fix to what is clearly a bug in Clearwin+, since the '@-anything' sequence doesn't seem to have any actual functionality associated with it -- or at least a compiler switch or linker option to prevent it happening. I would really appreciate a comment on this from someone in Silverfrost. I'm considering buying a new version of the compiler, but this problem is likely to delay the decision because it will delay my product development!
_________________
(Steve Henley)