The language of the display is not the issue, I think we have a communication or terminology gap here. Let me give you an example of what I am trying to say. Let's use English and Hebrew (you used Arabic, similar concept). We have a US Windows pc with English VFP 9. We want to have an application that allows the user to enter English or Hebrew in text fields, the values of which will be stored in example.dbf, our application table.

First thing is you cannot change the default non-Unicode lamguage without ruining the pc's windows. All non-Unicode programs will start displaying that language, and not English. We obviously do not want that. We want an English computer in which my application allows the entry of other languages, in this case Hebrew.

I have a form with 4 text fields tied to field1, field2, field3, field4 in example.dbf.

Now how will I keep my data? If I try and set the codepage of example.dbf to the Hebrew codepage, VFP produces an error and will not allow that. On my form, thanks to Windows multilingual settings, I can type Hebrew, English, or any other language. But example.dbf uses the english codepage, and so only english ascii characters can be stored in it. If I enter Hebrew characters in a textbox on my form, it will look good while the form is open, but saving the data produces gibberish in the table - VFP receives from Windows some Unicode Hebrew characters and has no idea how to handle them. And VFP will not allow you to convert the text first to a Hebrew ascii codepage, because of the above issue with VFP not supporting that codepage on English Windows. There is literally no way to accept those Hebrew characters, store them as Hebrew characters, and retrieve them and display them in Hebrew,. It cannot be done with the native VFP capabilities.

(Note that, as per the VFP docs, the.righttoleft property is ignored in US Windows and only respected in Hebrew or Arabic Windows.)




>>You cannot writre to or read correctly all code pages, VFP supportsa subset of code pages depending on the version of Windows.Try ? cpconvert(1252,1255,"hello").
>>
>>The key is that what you can display on screen in Windows is not related to what VFP will use as a codepage.
>
>That's why there's a nonunicode programs language combobox at regional settings.
>
>All unicode applications can use all codepages at same time, VFP is a nonunicode language, it just show language selected by "nonunicode programs language combobox at regional settings".
>
>I don't understand what you want to show with cpconvert command? We use cpconvert translate words between turkish dos (857), turkish windows (1254).