Problems with garbage characters in Chinese Win7 under VS2008.
in [MFC]
|
From: David on 8 Feb 2010 23:05 On Feb 7, 12:58 pm, "Liviu" <lab...(a)gmail.c0m> wrote: > "David" <dgi...(a)gmail.com> wrote... > > >>> The problem is that it does not work on Win7 English edition > >>> with Hong Kong language pack. > > [...] > > To sum up the solution: > > 1) The difference between the native Hong Kong Win7 system and an > > English system with HK language pack appears to be that the locale > > used for non-Unicode programs on the latter system is the English- > > language locale, while the HK-native version of course used the HK > > locale. Hence, the English-language version doesn't use the 8-bit > > characters against the correct code page (950) and doesn't have the > > correct characters. > > 2) VS6 apparently apparently defaults to the USER's default locale > > (and code page) as specified in the .rc file while VS2008 doesn't do > > so. > > 3) The solution is to add a call to > > SetThreadLocale(LOCALE_USER_DEFAULT) to the program. > > Then all works properly. > > If the above did indeed fix the problem, then you may have been bit > byhttp://msdn.microsoft.com/en-us/library/w1sc4t4k.aspx > > "In versions of ATL up to and including ATL 3.0 in Visual C++ 6.0, > string conversions using the macros in atlconv.h were always performed > using the ANSI code page of the system (CP_ACP). > Starting with ATL 7.0 in Visual C++ .NET, string conversions are > performed using the default ANSI code page of the current thread" > > (and the same applies to _wcstombsz, _mbstowcsz). > > However, in that case, there must be more to your code than the > (over)simplified LoadString + SetWindowText you quoted earlier. > > Liviu- Hide quoted text - > > - Show quoted text - As I've said in other posts, this problem has been solved and fixed. As for the comment "there must be more to your code...", I showed all of the code in the test program. It was simplified from the production application but the code provided was sufficient to show the problem.
From: David on 8 Feb 2010 23:12 On Feb 8, 4:32 am, "Mihai N." <nmihai_year_2...(a)yahoo.com> wrote: > >> Must be Unicode for that. > > Not true. The resources are built with 8-bit ANSI code-page specific > > characters. I have solved the problem and gotten this to work > > properly. > > The .rc files get compiled to .res, and the .res files are always > Unicode, it does not matter if the .rc files are Unicode or not. > The code page uset to convert to Unicode is specified by > #pragma code_page or the /c switch in the resource compiler. > (the pragma takes priority) The .rc files specify the code page with directives within the file. > > At runtime the Unicode resources get loaded and used as is > if the application is Unicode, or converted to the ANSI code > page for non-Unicode applications. > Even you the resource loading starts using the thread locale > instead of the system locale, you will get big-5 strings in > an ANSI application running on a system with 1252 system code > page. So using the big-5 strings will lead to bugs down the line. > Loading them from resources is only half of the problem. > So you will see other bugs down the line. The resource files contain 8 bit characters (not unicode as I haven't built with that flag set). I know that big-5 strings are present and require code page 950. The only time I use the Traditional Chinese version of the strings (from a DLL I load based on current language), is when the user's specified language/locale is 0404 or 0c04 (and hence, code page 950 is the active CP). The problem is that even in that situation, the system is using the system's native (English) code page. By explicitly setting the locale (SetThreadLocale(LOCALE_USER_DEFAULT);) the correct code page (950) is used. I've built the application and verified that it works properly so whatever others in this thread may think, the analysis and solution are valid. > > The only way to safely run a Traditional Chinese application is > to set the system code page to 950 (by setting the language > for non-Unicode applications) or by making your application > Unicode. > > Any other "solution" is unsupported, and will give you all > kind of problems. > > -- > Mihai Nita [Microsoft MVP, Visual C++]http://www.mihai-nita.net > ------------------------------------------ > Replace _year_ with _ to get the real email Regards, David
From: Liviu on 9 Feb 2010 00:24 "David" <dgintz(a)gmail.com> wrote... >On Feb 7, 12:58 pm, "Liviu" <lab...(a)gmail.c0m> wrote: >> "David" <dgi...(a)gmail.com> wrote... >> >>>>> The problem is that it does not work on Win7 English edition >>>>> with Hong Kong language pack. >>> [...] >>> To sum up the solution: >>> 1) The difference between the native Hong Kong Win7 system and an >>> English system with HK language pack appears to be that the locale >>> used for non-Unicode programs on the latter system is the English- >>> language locale, while the HK-native version of course used the HK >>> locale. Hence, the English-language version doesn't use the 8-bit >>> characters against the correct code page (950) and doesn't have the >>> correct characters. >>> 2) VS6 apparently apparently defaults to the USER's default locale >>> (and code page) as specified in the .rc file while VS2008 doesn't do >>> so. >>> 3) The solution is to add a call to >>> SetThreadLocale(LOCALE_USER_DEFAULT) to the program. >>> Then all works properly. >> >> If the above did indeed fix the problem, then you may have been bit >> by http://msdn.microsoft.com/en-us/library/w1sc4t4k.aspx >> >> "In versions of ATL up to and including ATL 3.0 in Visual C++ 6.0, >> string conversions using the macros in atlconv.h were always >> performed using the ANSI code page of the system (CP_ACP). >> Starting with ATL 7.0 in Visual C++ .NET, string conversions are >> performed using the default ANSI code page of the current thread" >> >> (and the same applies to _wcstombsz, _mbstowcsz). >> >> However, in that case, there must be more to your code than the >> (over)simplified LoadString + SetWindowText you quoted earlier. > > As I've said in other posts, this problem has been solved and fixed. Maybe "fixed" or patched, rather than "solved". I agree with others' advice that the only actual "solution" is moving to Unicode. The SetThreadLocale documentation http://msdn.microsoft.com/en-us/library/dd374051(VS.85).aspx does mention a number of caveats, to the effect of "don't use it". > As for the comment "there must be more to your code...", I showed all > of the code in the test program. It was simplified from the production > application but the code provided was sufficient to show the problem. I won't really argue this point, since I don't have an HK-native test machine handy to verify myself. However, I am still curious as to why your app's locale was other than the user's default one, and needed to be explicitly forced back to LOCALE_USER_DEFAULT. Liviu
From: Leslie Milburn on 9 Feb 2010 03:29 "David" <dgintz(a)gmail.com> wrote in message news:b25b0f17-7f87-4ca4-9cb7-723b57e32505(a)o28g2000yqh.googlegroups.com... > The resource files contain 8 bit characters (not unicode as I haven't > built with that flag set). David, I think you misunderstand this point. Regardless of your #defines and other settings at compile time, the rc and dlg files *are always* double byte characters - I know for a fact this is the case for Visual C/C++ 6 as I am using it. So even if the application is non-unicode the dialog templates are still stored with double byte characters. Leslie.
From: Alexander Grigoriev on 9 Feb 2010 10:34 No. Only the _compiled_ resources are always double-byte (more precisely, UTF-16). RC files can be single-byte, UTF-8, or MBCS, or UTF-16. "Leslie Milburn" <CDB4W(a)NOSPAM.bigpond.com> wrote in message news:OeNM6HWqKHA.4636(a)TK2MSFTNGP06.phx.gbl... > > "David" <dgintz(a)gmail.com> wrote in message > news:b25b0f17-7f87-4ca4-9cb7-723b57e32505(a)o28g2000yqh.googlegroups.com... > >> The resource files contain 8 bit characters (not unicode as I haven't >> built with that flag set). > > David, > > I think you misunderstand this point. Regardless of your #defines and > other settings at compile time, the rc and dlg files *are always* double > byte characters - I know for a fact this is the case for Visual C/C++ 6 as > I am using it. So even if the application is non-unicode the dialog > templates are still stored with double byte characters. > > Leslie. >
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Find out how many records in a SQL Table Next: How to get user SID? |