Comparison of (Ansi) strings

[GregG]

Hi Chris,

Chr(128) returns C7 and ChrW(128) returns 3F. What is the correct, in a VO-compatible application with SetAnsi(False), to get the value of 128 to be 80?

Thanks,

Greg

[Chris]

Hi Greg,

You mean 80 in hex right? In this case, you need to use ChrW(), this alternative version of Chr() does not make any ansi<->unicode conversions, and instead returns the unicode char with the exact value you specified. Not there's also AscW(), which does the opposite thing (since Asc() also does unicode/ansi conversions)

[GregG]

Hi Chris,

Yes, sorry, I should have clarified that we're trying to get 0x80. As mentioned, ChrW(128) results in a hex value of 3F.

Thanks,

Greg

[Chris]

Hi Greg,

Oh, sorry, I did not read your post carefully enough! But there is no reason for ChrW() to return anything else than the exact value you pass to it. How are you checking what is the actual value? You must not use Asc() for that, because this will also do ansi<>unicode conversions, while AscW() will indeed give you the actual unicode value. If it's not Asc() that you are sing, can you please show how you do the check, or where you see the result of ChrW(128) being different from 128?

[boonnam]

Chris,

We are writing ChrW(128) to a text file and reading it with a hex editor shows a value of 3F.

0-127 appear to be correct, and so are values 129-255.

[Chris]

Hi Boonam,

OK, that's because also the file read/write functions (FWrite() etc) do ansi<>unicode conversions, that's necessary in order to correctly output international characters. Edit: That is, if you are using those functions to output the data of course!

Is it only this 128 char that you want to write in the file as "binary" value and the rest of the contents are normal text? In this case, you must actually use Chr(128) (not ChrW(128)), because the two conversions will cancel each other and the char value of 128 will be saved on disk.

If it's all binary data, then you should better use the FWrite3() function that deals with it, or even better use methods of the System.IO.File class, which give you full control over how you write the data to disk.

Also please keep in mind that if you are using FRead() and similar functions to read back the data, there are again ansi to unicode conversions taking place that you have to consider, since even though the byte 128 has been written on disk, FRead() will result to a different char...

I know, it can become really complicated, so I think the best way to deal with this is to please tell us exactly how you are using those files and what kind of text and data are written to it, so we can suggest the best way to deal with all those conversions.