|
Prev: .NET Memory Woes
Next: Need help with report writing
From: Henryk Birecki on 28 Jan 2008 13:21 How do I get strings with multiple languages (let's say a mix of english, russian, japanese characters) to display in a Unicode enabled application (MFC42U.dll). I read data from file that is utf8, convert them to WCHAR and want to display resulting strings. CEdit and CListbox controls have Arial MS Unicode font selected into them that contains all the characters. The WCHAR strings have correct information as I can check that in debugger, however when displayed in controls, english is fine but all else is displayed with "ANSI" equivalents (read: "gibberish") instead of proper characters. Can someone point me to what I may be doing wrong, or what needs to be done to accomplish what I need? Thanks, Henryk Birecki
From: Henryk Birecki on 28 Jan 2008 13:57 Thanks Paul, Font definitely stays around and has all the required glyphs. I can see font changes in the controls as I can select required font in my program by user selection, and it is easy to use character map utility to check for the glyphs. For testing I use Arial MS Unicode. I have not tried a "simple application" as yet (I will, but this is still different from CEdit...), but my first guess is that something connected to "locale" is getting in the way. Unfortunately, this is an area that I know nothing about. Cheers, Henryk "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com> wrote: >My guess would be, obviously, that you do not have a font selected that >includes all of the glyphs. If you want a simple test to get a better >handle of what's going on, build a simple, non-MFC test program using the >New Project wizard in your development IDE. This typically results in a >Hello, World program that will draw that string on the main window. Adjust >the string that is drawn to be one of your Unicode strings and create and >select the font that you think you're using with CEdit and CListbox. What >result? If you still don't get the right glyphs, I'd bet that either a) the >font doesn't have them (most-likely), or b) you are not creating the font >properly. > >If the correct glyphs are displayed, you should check that you are correctly >setting the font as the font for your controls. You might be using the >wrong message to do this, MFC might be ignoring some sort of SetFont() call, >or you might be freeing the font after you set it into the control instead >of keeping it around. > >Paul T. > >"Henryk Birecki" <soaringpilot(a)sbcglobal.net> wrote in message >news:pb6sp313ghd3b093936543ect5mnh1dc87(a)4ax.com... >> How do I get strings with multiple languages (let's say a mix of >> english, russian, japanese characters) to display in a Unicode enabled >> application (MFC42U.dll). I read data from file that is utf8, convert >> them to WCHAR and want to display resulting strings. CEdit and >> CListbox controls have Arial MS Unicode font selected into them that >> contains all the characters. The WCHAR strings have correct >> information as I can check that in debugger, however when displayed in >> controls, english is fine but all else is displayed with "ANSI" >> equivalents (read: "gibberish") instead of proper characters. >> >> Can someone point me to what I may be doing wrong, or what needs to be >> done to accomplish what I need? >> >> Thanks, >> Henryk Birecki >
From: "Paul G. Tobey [eMVP]" p space tobey no spam AT no instrument no spam DOT on 28 Jan 2008 14:37 Rendering of text using the selected font doesn't care what the locale is, generally, other than right-to-left and so on. I've done Greek characters on an English-only device, for example (and I just verified that it works fine), with no problems. What character set are the extra characters from? I think that the problem is in the specifics of your device and what you're trying to display, not some general problem with MFC, particularly on the desktop, where much is different. I'm not claiming that this is the same as an EDIT control, but it will tell you if you really have the right font and the right string because you have complete control over drawing, in this case. Paul T. "Henryk Birecki" <soaringpilot(a)sbcglobal.net> wrote in message news:vr8sp3t2vrd97m5kq6u4cullqspe8e2l9a(a)4ax.com... > Thanks Paul, > > Font definitely stays around and has all the required glyphs. I can > see font changes in the controls as I can select required font in my > program by user selection, and it is easy to use character map utility > to check for the glyphs. For testing I use Arial MS Unicode. > > I have not tried a "simple application" as yet (I will, but this is > still different from CEdit...), but my first guess is that something > connected to "locale" is getting in the way. Unfortunately, this is an > area that I know nothing about. > > Cheers, > Henryk > > "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam > DOT com> wrote: > >>My guess would be, obviously, that you do not have a font selected that >>includes all of the glyphs. If you want a simple test to get a better >>handle of what's going on, build a simple, non-MFC test program using the >>New Project wizard in your development IDE. This typically results in a >>Hello, World program that will draw that string on the main window. >>Adjust >>the string that is drawn to be one of your Unicode strings and create and >>select the font that you think you're using with CEdit and CListbox. What >>result? If you still don't get the right glyphs, I'd bet that either a) >>the >>font doesn't have them (most-likely), or b) you are not creating the font >>properly. >> >>If the correct glyphs are displayed, you should check that you are >>correctly >>setting the font as the font for your controls. You might be using the >>wrong message to do this, MFC might be ignoring some sort of SetFont() >>call, >>or you might be freeing the font after you set it into the control instead >>of keeping it around. >> >>Paul T. >> >>"Henryk Birecki" <soaringpilot(a)sbcglobal.net> wrote in message >>news:pb6sp313ghd3b093936543ect5mnh1dc87(a)4ax.com... >>> How do I get strings with multiple languages (let's say a mix of >>> english, russian, japanese characters) to display in a Unicode enabled >>> application (MFC42U.dll). I read data from file that is utf8, convert >>> them to WCHAR and want to display resulting strings. CEdit and >>> CListbox controls have Arial MS Unicode font selected into them that >>> contains all the characters. The WCHAR strings have correct >>> information as I can check that in debugger, however when displayed in >>> controls, english is fine but all else is displayed with "ANSI" >>> equivalents (read: "gibberish") instead of proper characters. >>> >>> Can someone point me to what I may be doing wrong, or what needs to be >>> done to accomplish what I need? >>> >>> Thanks, >>> Henryk Birecki >> >
From: Serge Wautier on 28 Jan 2008 14:36 The first think I'd check is that the source text is correctly converted from UTF-8 to UTF-16. (BTW, how do you do it? MultiByteToWideChar(CP_UTF8,...) comes to mind). As far as font is concerned, Windows is in most (not all!) cases smart enough to fallback to a best suited font if yours doesn't contain the required glyphs. Hence this wouldn't be my first concern. Put a breakpoint somewhere and check that the WCHAR strings contains the expected code points. You may want to check the correspondance between UTF8 and UTF16 for a few faulty characters. Go here: http://www.fileformat.info/info/unicode/char/0409/index.htm HTH, Serge. http://www.apptranslator.com - Localization tool for your MFC applications "Henryk Birecki" <soaringpilot(a)sbcglobal.net> wrote in message news:vr8sp3t2vrd97m5kq6u4cullqspe8e2l9a(a)4ax.com... > Thanks Paul, > > Font definitely stays around and has all the required glyphs. I can > see font changes in the controls as I can select required font in my > program by user selection, and it is easy to use character map utility > to check for the glyphs. For testing I use Arial MS Unicode. > > I have not tried a "simple application" as yet (I will, but this is > still different from CEdit...), but my first guess is that something > connected to "locale" is getting in the way. Unfortunately, this is an > area that I know nothing about. > > Cheers, > Henryk > > "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam > DOT com> wrote: > >>My guess would be, obviously, that you do not have a font selected that >>includes all of the glyphs. If you want a simple test to get a better >>handle of what's going on, build a simple, non-MFC test program using the >>New Project wizard in your development IDE. This typically results in a >>Hello, World program that will draw that string on the main window. >>Adjust >>the string that is drawn to be one of your Unicode strings and create and >>select the font that you think you're using with CEdit and CListbox. What >>result? If you still don't get the right glyphs, I'd bet that either a) >>the >>font doesn't have them (most-likely), or b) you are not creating the font >>properly. >> >>If the correct glyphs are displayed, you should check that you are >>correctly >>setting the font as the font for your controls. You might be using the >>wrong message to do this, MFC might be ignoring some sort of SetFont() >>call, >>or you might be freeing the font after you set it into the control instead >>of keeping it around. >> >>Paul T. >> >>"Henryk Birecki" <soaringpilot(a)sbcglobal.net> wrote in message >>news:pb6sp313ghd3b093936543ect5mnh1dc87(a)4ax.com... >>> How do I get strings with multiple languages (let's say a mix of >>> english, russian, japanese characters) to display in a Unicode enabled >>> application (MFC42U.dll). I read data from file that is utf8, convert >>> them to WCHAR and want to display resulting strings. CEdit and >>> CListbox controls have Arial MS Unicode font selected into them that >>> contains all the characters. The WCHAR strings have correct >>> information as I can check that in debugger, however when displayed in >>> controls, english is fine but all else is displayed with "ANSI" >>> equivalents (read: "gibberish") instead of proper characters. >>> >>> Can someone point me to what I may be doing wrong, or what needs to be >>> done to accomplish what I need? >>> >>> Thanks, >>> Henryk Birecki >> >
From: "Paul G. Tobey [eMVP]" p space tobey no spam AT no instrument no spam DOT on 28 Jan 2008 14:43
Hmmm. Looking at your set of targeted groups, again, I'm wondering...this is Windows CE, as group microsoft.public.windowsce.embedded.vc would indicate, or not? If not, I'll leave you in the capable hands of the other guys. Another good reason to carefully limit the number of groups you cross-post to... Paul T. "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com> wrote in message news:%23cRioUeYIHA.5416(a)TK2MSFTNGP05.phx.gbl... > Rendering of text using the selected font doesn't care what the locale is, > generally, other than right-to-left and so on. I've done Greek characters > on an English-only device, for example (and I just verified that it works > fine), with no problems. What character set are the extra characters > from? I think that the problem is in the specifics of your device and what > you're trying to display, not some general problem with MFC, particularly > on the desktop, where much is different. > > I'm not claiming that this is the same as an EDIT control, but it will > tell you if you really have the right font and the right string because > you have complete control over drawing, in this case. > > Paul T. > > "Henryk Birecki" <soaringpilot(a)sbcglobal.net> wrote in message > news:vr8sp3t2vrd97m5kq6u4cullqspe8e2l9a(a)4ax.com... >> Thanks Paul, >> >> Font definitely stays around and has all the required glyphs. I can >> see font changes in the controls as I can select required font in my >> program by user selection, and it is easy to use character map utility >> to check for the glyphs. For testing I use Arial MS Unicode. >> >> I have not tried a "simple application" as yet (I will, but this is >> still different from CEdit...), but my first guess is that something >> connected to "locale" is getting in the way. Unfortunately, this is an >> area that I know nothing about. >> >> Cheers, >> Henryk >> >> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam >> DOT com> wrote: >> >>>My guess would be, obviously, that you do not have a font selected that >>>includes all of the glyphs. If you want a simple test to get a better >>>handle of what's going on, build a simple, non-MFC test program using the >>>New Project wizard in your development IDE. This typically results in a >>>Hello, World program that will draw that string on the main window. >>>Adjust >>>the string that is drawn to be one of your Unicode strings and create and >>>select the font that you think you're using with CEdit and CListbox. >>>What >>>result? If you still don't get the right glyphs, I'd bet that either a) >>>the >>>font doesn't have them (most-likely), or b) you are not creating the font >>>properly. >>> >>>If the correct glyphs are displayed, you should check that you are >>>correctly >>>setting the font as the font for your controls. You might be using the >>>wrong message to do this, MFC might be ignoring some sort of SetFont() >>>call, >>>or you might be freeing the font after you set it into the control >>>instead >>>of keeping it around. >>> >>>Paul T. >>> >>>"Henryk Birecki" <soaringpilot(a)sbcglobal.net> wrote in message >>>news:pb6sp313ghd3b093936543ect5mnh1dc87(a)4ax.com... >>>> How do I get strings with multiple languages (let's say a mix of >>>> english, russian, japanese characters) to display in a Unicode enabled >>>> application (MFC42U.dll). I read data from file that is utf8, convert >>>> them to WCHAR and want to display resulting strings. CEdit and >>>> CListbox controls have Arial MS Unicode font selected into them that >>>> contains all the characters. The WCHAR strings have correct >>>> information as I can check that in debugger, however when displayed in >>>> controls, english is fine but all else is displayed with "ANSI" >>>> equivalents (read: "gibberish") instead of proper characters. >>>> >>>> Can someone point me to what I may be doing wrong, or what needs to be >>>> done to accomplish what I need? >>>> >>>> Thanks, >>>> Henryk Birecki >>> >> > > |