>Mornin' George,

Mornin' Steve,

>>
>>Steve,
>>
>>Something clicked in my head
>
>
>Did it hurt? <g>

No, the beer eased that problem.:-)

>>since I made my last post on this subject. VFP has two functions that may be of interest even though they're provided strictly for backward compatibility. They are OEMTOANSI() and ANSITOOEM(). What they do is convert between the two character sets. Try the following in the command window:

? OEMTOANSI(CHR(21))
>>? ASC(OEMTOANSI(CHR(21)))

>The first will display the § character, the second will return 167.
>>
>
>That is interesting. So, I wanted to see how it would work with another problematic EDI characters One possible EDI element seperator is chr(127), which looks like homeplate (yes, baseball) in ASCII. It displays properly in FoxFont, but the OEMTOANSI() still renders it incorrectly (I'm using that term loosely) in other fonts.
>
>According to HackFox, OEMTOANSI() works for characters 15, 20, 21 and those above 128.
>
>Thanks for the additional info...

I did some more tests and it appears that if you were the whole string to OEMTOANSI() all the necessary changes would be made within the entire string. I thought this might be of interest for two reasons. First, FoxFont has to be one of the ugliest fonts I've ever seen and you might want, for the sake of consistency to use whatever default font you would normally. Second, I'm not 100% certain that FoxFont is re-distributable. If it isn't then this solution might be better. Even if it is, you won't have to make sure that it's installed in the font table for the users. So in either case, you might be better off using the function.