Problem with 'at' character input/output

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 %

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

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.

program testchars 
character*1 testch 

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

write (*,1) 'defined format test'
write (*,1) 'this should display four at chars @@@@' 
write (*,1) 'please input char @' 
read  (*,2) testch 
write (*,1) 'character entered=',testch 
1 format (1x,a,a)
2 format (a)
!
pause 
stop 
end 

ftn95 at.f95 /lgo >zz

file : zz
[FTN95/Win32 Ver. 6.35.0 Copyright (c) Silverfrost Ltd 1993-2013]

    NO ERRORS  [<TESTCHARS> FTN95/Win32 v6.35.0]
Creating executable: c:\\TEMP\\lgotemp@.exe
Program entered
 free format test
 this should display four at chars @@@@
 please input char @
 character entered=@
 defined format test
 this should display four at chars @@@@
 please input char @
 character entered=@
***Pause: 
Enter system command or press ENTER key to restart: 

Try the following which shows @@ > @, but @x > .nothing. write (,) 'this should display four at chars %@@@@...@@..@xy'

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.

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

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.

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.

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

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,

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:

      PROGRAM AT
      WRITE(*,*) '@@@'
      WRITE(*,*) CHAR(64),' ', CHAR(64),' ',CHAR(64)
      END 

This works as you would expect it to. Prefix the program with the WINAPP directive, however, and the behaviour you note is immediately obvious.

Sadly, C (with or without any variations such as ++) is an alien language to me. Since Microsoft-speak is Klingon, perhaps this is Vulcan or Romulan. Anyway, a little internet search does reveal that @ has a C significance in strings. The translator module in my starship/shed is non-functional at present (and is likely to be for the indefinite future) ...

As so often, the problem comes down to the excessive brevity of FTN95.CHM. I did a search in it for @, and it is listed, but with a description that seems to me to be just plain wrong (or maybe it is in Navajo).

Eddie

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...

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

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

Quoted from silicondale

Thanks for the suggestion, but I'm afraid it doesn't help, as it IS output that is the problem.

My idea was to handle the input and output separately. How about doing something like...

module test
  use mswin
  implicit none

  character(len=80) :: input_buf

  contains
    integer function input_handler()
      integer :: i, j
      character(len=160) :: output_buf

      output_buf = ''
      j =1

      do i = 1,80,1
        if (input_buf(i:i) == '@') then
          output_buf = output_buf(:j) // '@@'
          j = j + 1
        else
          output_buf = output_buf(:j) // input_buf(i:i)
        end if
        j = j + 1
      end do    

      write(*,*) trim(output_buf)
      input_buf = ''

      input_handler = 1
    end function input_handler

end module test

                                                                    
winapp 
program test1
   use test
   integer :: i
   
   i=winio@('%ca[Test proggy]&')
   i=winio@('%mn[E&xit]&','EXIT')
   i=winio@('%ob%80.20cw[vscroll]%cb&',0)
   i=winio@('%ff%80rs&',input_buf)
   i=winio@('  %`^bt[OK]',input_handler)
end program test1

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,

You have identified the problem of the 'lazy' clearwin output window not displaying @, but how about using the active window, say in a %ws or %rs box. Have you tested these to see what happens ? I have menu structures which give display windows for updating data. I have not tested them to see if these can accept @, but they may well work differently to the output window, which I use as a background window for debugging information, as a second screen.

Also, a tab character is a special character for input and output which behaves differently, so there are other special characters for data transfer. You try and find how to handle the use of tab in the documentation !!

John

Ps: I just tried changing the names of some items listed in a %ls box and the @ displayed without any problems. The names were read from a text file into a character string, then displayed correctly as listed in the text file.

Hi John - Good point. I was using the 'lazy' Clearwin window mainly because it's quite a large legacy application and it would be a mammoth task to re-code all the write statements that output to the display. However, I guess I should look again at the feasibility of this. If I can associate a LUN with a %ws window then perhaps it's possible.

Yes, you're right about the tab character, also the LF and CR of course - but these are positioning characters, not display characters. When you press the @ key on the keyboard you expect an @ to be displayed on the screen. The fact remains that without any documentation of the weird behaviour, it has to be considered a bug.

Re:

If I can associate a LUN with a %ws window

I don't think you can. But you can embed a programmed clearwin window using %cw ... although don't get excited, it displays the same behaviour as the 'lazy' window.

      WINAPP
      PROGRAM AT
      INCLUDE <WINDOWS.INS>
      INTEGER, EXTERNAL:: WRITEAT
      IA = WINIO@('%ca[Test for embedded CW window]%2nl%pv'//
     &            '%70.30cw[vscroll,hscroll]&',
     &             99)
      IA=WINIO@('%ww%sc&', WRITEAT)
      IA=WINIO@('%ff%nl%rj%12bt[STOP]'//
     &          '%lw', KONTROL)
      STOP
      END
      INTEGER FUNCTION WRITEAT()
      WRITE(99,*) '@@Blimey!'
      WRITEAT = 1
      RETURN
      END 

You would have to use double-@ every time to use this, which is what you would have to do with the lazy window ...

Eddie

Thanks, Eddie! Good idea, pity it didn't help. Think for now I'll just cut my losses and use ~ instead of @ for the prefix, and hope that no users have any @ characters embedded within their data!

cheers

Steve

Steve,

I have used the menu system to create data entry forms. With a little bit of effort and a review of the data structures you want for the user interface, they can be very effective. You need to balance interactive (slow) with file inputs (require skill from the user) Also need to consider how you get an interupt to review the data that has been entered. I have used %ls as a selection control, then update the table below for data associated with this %ls selection. (you need a call-back on the %ls selection) %rd and %rf boxes work very well for data, with a few labels. You need to control when you take the updated info and review for errors. ( even an ok button can work.)

Above the %ls I also have some fixed %rd, %rf and %rs fields for key controls of the run. (a %rs field can be updated by the user or program to control the run option label)

If as I find, there are only a few key data structures that require this approach, while lots of other data is in files, then you can get a more effective solution with only a few data interface menu options. It realy is worth experimenting. You'll waste a few nights with the layout !

Eddie has much more experience in this area, so he might have more ideas.

John