>>My client wants to input the Russian characters, such as БПЭ3-1003ПТМ
>>but when I copy & paste, it becomes ???3-1003???
>>is that a way to accept that characters?
>
>Fox is not Unicode, and the clipboard is under influence of whatever windowses think is the proper character set for the current machine.
>
>Assuming that VFP's codepage is set to 1251, you still need to set the system codepage for non-unicode apps to 1251. Requires a reboot and can't be set per user, it's for the whole machine. Of course, then you'll have trouble with other codepages. Well at least your other codepage is 1252, which is a subset of every other one, so this shouldn't be a problem. The problem would be if you wanted to do both, say, polish and russian on the same box - you couldn't possibly keep them in the same table, unless you keep them stored as binary, in UTF8 or something, and manage the input and display with lots of acrobatics.
>
>IOW, the best you can do is to use one character set, and languages which can use that character set, which is mostly one western and all those native to that set.

Speaking of codepage stuff... Something that I found out by experience is to avoid string constants in your code containing characters in the "upper-ASCII" range -- especially if you have to East Asian language systems (e.g. Chinese, Japanese, Korean) where double-byte character systems are used. You may find that a program that works fine in English codepage now start throwing seemingly spurious errors (e.g. syntax errors) when run in system configured for Chinese, Japanese or Korean. This is mainly because the character codes in the "upper-ASCII" range (ASCII value 128 - 255) are used as prefix bytes that alter the meaning of one or more following bytes. If a string constant contains such a character at the end, the closing of the string (e.g. the ending apostrophe, double-quote or closing square bracket) could get "eaten" (i.e. not interpreted as the end of string constant) resulting in runtime errors.