Odd change experienced ....

I have come across a weird change. One of my programs contains this line:

      I=WINIO@('%nlTraverse Root name (2 letters e.g. AA)'//
     &         '%fn[Arial]%ts%`bg[white]%3^rs%sf&',
     &          1.25D0, A0,  iRoot)

A0 is CHARACTER*(2)

Using a straight version of FTN95 6.10 with no changes to salflibc.dll, I can enter 2 characters into the box before I get a 'bing' sound. Using the beta salflibc.dll, I can only enter 1 character before I get the 'bing'. This is not anything to do with the callback function iRoot, although iRoot does contain BEEP@, because I have tried it with WRITE statements before and after the BEEP@s, and they are not accessed. Moreover, if I make the character variable A0 into CHARACTER*(3), I can get the desired 2 character input, and only get 'bing' when I try a 3rd character in input.

I have tried this with my 6.10 (with beta salflibc.dll) and also 6.35 pe version (again with beta salflibc.dll). I also tried increasing the %3^{rs to %5}rs, to no effect. I wonder if it is one of those dreaded 'reversions'?

A tiny test code that shows it is:

      WINAPP
      PROGRAM SURVEYOR
      CHARACTER*(2) A2 ! allows 1 character only
      CHARACTER*(3) A3 ! allows 2 characters
      INTEGER, EXTERNAL:: iRoot
      INCLUDE <WINDOWS.INS>
      A2='  '
      A3='   '
      I=WINIO@('%nlTraverse Root name (1 letter only e.g. A) '//
     &         '%fn[Arial]%ts%`bg[white]%3^rs%sf&',
     &          1.25D0, A2,  iRoot)
      I=WINIO@('%2nlTraverse Root name (2 letters e.g. AA) '//
     &         '%fn[Arial]%ts%`bg[white]%3^rs%sf&',
     &          1.25D0, A3,  iRoot)
      I=WINIO@('%sf')
      END
      INTEGER FUNCTION iRoot()
      iRoot = 1
      END

The program gets an outing once a year for a week, and this is the week! (My colleague who is using it, knows that I am an inveterate tinkerer, and thinks that I have changed something ...)

Eddie

PS - ignore the superfluous %sf.

I think that is change results from a fix in salflibc.dll. This change limits the size of the edit buffer for %rs to the size of the related character variable. Otherwise ClearWin+ will copy back more characters than there is space for.

It is possible that I should have allowed one more character but this may have something to do with a NULL terminator in C.

I will log this for investigation.

I am sure that it is something of the kind. I was already allowing for letters bigger than an average by specifying %3rs when I only wanted 2, and it is definitely a change. You wouldn't notice it so easily for a long string.

Eddie

I have fixed this for the next beta release (coming shortly I hope).