>Hi Albert,
>
>Howareya? Sorry for the delay -- I just got back from a trip. [SMB] comments below.
>
>I get the following results with cpcurrent() with these OS/FoxPro combinations:
>
>1) Windows 3.2 Simplified Chinese / FoxPro 2.6a and VFP 3.0b
>
>cpcurrent() = 936
>cpcurrent(1) = 936
>cpcurrent(2) = 936
>
>[SMB] This looks fine to me since this version of Windows runs on top of DOS. Does your configuration file say CODEPAGE=AUTO or CODEPAGE=936? I'm guessing the latter.

[ajb] My configuration file says CODEPAGE=AUTO. We use a dual boot setup where the operator can bootup in English Windows or Chinese Windows. We don't want to specify a particular codepage in with this arrangement.

>
>
>>
>>1) Windows NT 4.0 Pan Chinese / FoxPro 2.6a
>>
>>cpcurrent() = 0
>>cpcurrent(1) = 1252
>>cpcurrent(2) = 936
>>
>
>[SMB] According to Nadine Kano this cpcurrent(2) result is normal (or at least it was in NT 3.51 and I doubt it has changed). IOW this is the expected result under far-eastern versions of Windows NT 3.51 or better. See page 288 of "Developing International Software" (N. Kano, MS Press, ISBN 1-55615-840-8). At this level this is a reference book you need <s>.
>
>Are you successfully displaying Chinese in FP 2.6a? If so, DBCS string length reckoning issues aside, any side-effects?

[ajb] I am successfully displaying Chinese in FPW 2.6a and VFP 3.0 on Chinese Windows 3.2 with no problems.

>
>
>>1) Windows NT 4.0 Pan Chinese / VFP 3.0b and VFP 5.0a
>>
>>cpcurrent() = 936
>>cpcurrent(1) = 936
>>cpcurrent(2) = 936
>>
>
>[SMB] Are these two results taken fron the same NT 4 machine?
>
>>My applications use the active codepage to select the language to display.
>>
>
>[SMB] That's a cute trick.
>
>
>>VFP 3.0b generates a GPF in the VFP300.ESL when a form is opened, but VFP 5.0a runs OK.
>
>[SMB] All forms or just a form. Same machine both?

[ajb] Seems to be any form, it affects more than one app.

>
>>
>>The Chinese strings are not displaying properly under VFP 5.0a. I get some Chinese characters mixed with '?' - question marks. We have the same mangled characters with 32bit Borland C++ 5.01 applications.
>>
>>Since Pan Chinese NT supports both Traditional Chinese and Simplified Chinese with an English Windows front end, are the mangled strings I am getting the result of trying to display Simplified Chinese strings with the Traditional Chinese character set active?
>>
>
>[SMB] Traditional Chinese is CP 950 and I don't see that anywhere here. Just kick me if I'm missing something.
>
>>Are there any recommendations for tweaking the application's runtime environment to solve these problems?
>
>[SMB] What is the CPDBF()? Really there are only a couple of things that can go wrong here, The font is certainly suspect since you're getting this effect in other packages. If it's not the font, then what are the odds that an inadvertant CP translation has happened here. Where does the data come from?

[ajb] The affected table is your STRINGS.DBF. The CPDBF() = 0, I store all my text with no codepage translation because I have one to many relations from the non-internationalized to the internationalized text, thus I simply filter the view by language and, presto chango, I have the text data in a different language. It would not be good to have FoxPro do cp 1251 conversions on cp 936 records, etc.

The font I am using is Arial, with the 2.6 version I used a Cyrillic font for all languages (English, Russian, Chinese) as a kludge because it worked with all of the currently supported languages and, The INTL 2.6 does not have a font strategy. Under Chinese Windows 3.2, Chinese characters were mapped into a SBCS font. Maybe I have to select a Chinese compatible font for NT?

>
>**--** Steve