problem writing file, works perfect on Windows Server 2012 R2, fails on Windows 10 - solved 2

[Stephan_Neumann]

Problem solved: turns out that Foxpro on Windows 10 automatically writes (some) special characters as double-byte characters. By replacing ÿ with chr(255) and û with chr(251) it is working again. Thanks Griff for the tip to use a hex editor!

I create an array of X data from a database and write it to a secundary file to be merged with Word or WordPerfect files. This has worked since 1995 without a flaw, currently on a Windows Server 2012 machine. In a new Windows 10 stand-alone version I'm recreating the program and use exactly the same code, and it doesn't work. It writes the data but with wrong control characters.
I have been looking at codepages, etc. but no clue. Any help appreciated!
Code:
hendel=fcreate(mhome+'nu.txt')
fwrite(hendel,'ÿWPC^'+chr(0)+chr(0)+chr(0)+chr(1)+chr(10))
fwrite(hendel,chr(0)+chr(1)+replicate(chr(0),4)+'ûÿ'+chr(5)+chr(0)+'2'+replicate(chr(0),5)+chr(6))
fwrite(hendel,chr(0)+chr(8)+replicate(chr(0),3)+'B'+replicate(chr(0),3)+chr(8)+chr(0)+chr(2)+replicate(chr(0),3)+'J')
fwrite(hendel,replicate(chr(0),3)+chr(1)+chr(0)+chr(18)+replicate(chr(0),3)+"L"+replicate(chr(0),13)+chr(8)+chr(0)+"|")
fwrite(hendel,chr(0)+'x'+replicate(chr(0),5)+'Jan 01, 1980'+replicate(chr(0),6))
For teller=1 To Alen(F)
F[teller]=trim(F[teller])
fwrite(hendel,f[teller]+end_field())
Next
fwrite(hendel,end_record())
fclose(hendel)
release F
return .T.

function END_FIELD
return chr(222) + "1" + chr(04) + chr(0) + chr(04) + chr(0) + "1" + chr(222)+chr(10)

function END_RECORD
return chr(222) + chr(52) + chr(6) + chr(0) + chr(0) + chr(0) + chr(6)+ chr(0) + chr(52) + chr(222) + chr(12)

 

[GriffMG]

Are you sure this isn't a representation/presentation thing?

Is it possible that one of your viewers is presenting the hex value xDE and the other showing an (incorrect) ASCII character xDE is chr(222)

Do you have a hex editor you could double check the file content with.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Stephan_Neumann]

Thanks Griff, but nope, it is not a (re)presentation thing, both Word and Wordperfect reject the file, Word says 'no data' and WP says 'unsupported file format'. Both accept the correct file without problem and merge it.
Regards, Stephan

 

[GriffMG]

Well, your code is producing the correct output (based on your code above) in the file you call BAD.

The file you call Correct would use chr(235) where your code has chr(222).

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

Welcome ot the forum, Stephen.

I haven't looked at your code in detail, but in general I would avoid using "upper ASCII" characters such as "û" and "ÿ" when transferring data out of VFP. In theory, it should work, but I would prefer to use CHR(), passsing the numeric codes.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

Hi Mike,

Where has he used upper()?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

What Mike says could be the root problem, mostly you're using CHR() calls, which make it totally clear what bytes are written to the txt file.

But I think Grifff also is right: Why would the TXT display in the charset you're used to. I assume this is someething like DOS codepage code, then you could try and set notepad to use the Font "Terminal" and that mkght look as expected.

Bye, Olaf.

 

[Mike Lewis]

Griff,

I wasn't referring to "upper" characters in the sense of capital letters (upper case). I was talking about the characters in the range 128 - 255. These include things like accented letters and currency symbols.

Sorry if I confused the issue. There might be a more correct of describing these characters, but I don't know what it is.

Edit: Just to further clarify - "û" would be CHR(251) and "ÿ" would be CHR(255).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I getcha Mike

On his screenshot the only difference that I can see is that the character at the positions produced by chr(222) seem to be chr(235) in the 'Correct' example.
fwrite() isn't affected by any locale setting or character set is it?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[GriffMG]

Thanks for the star, but I think Mike had the answer before me.


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

>fwrite() isn't affected by any locale setting or character set is it?

As I already said: chr() is surely never affected, but the strings you write as literal "ÿ", what code they get will depend on the PRG codepage. So to get certain bytes you better use CHR() and simpler would be using binary literals 0hhexadecimalsdigits, eg do this:

h = fcreate("test.txt")
fwrite(h,0h48656C6C6F2C20576F726C6421)
fclose(h)
modify file test.txt

That way you absolutely will have control about the byte values, as you express them as hex values.

The conversion might have been done when you first opened the old code in VFP. VFP will try to convert keeping the letters as they look and therefore change to other ansi bytes, when I assume your code originally was Fox DOS and Codepage 450 or 850 or something like that, this would explain it. As you wanted to encode certain ASCII/Byte Code, that should have all been done using CHR() or hex values.

Bye, Olaf.

 

[Stephan_Neumann]

Thank all of you for your contributions!