Unicode, CRichEditCtrl, SetWindowText and Paste
in [MFC]
|
Prev: ActiveX event and DoModal
Next: Error LNK2005: _DllMain@12 already defined in msvcrtd.lib(dllmain.obj) mfcs90ud.lib
From: andrew on 8 Dec 2009 22:58 I have a CRichEditCtrl in a Unicode application that will not display Khmer when I use SetWindowText but will display it when the same text is pasted from a Word document. Many other languages (e.g. Japanese, Chinese, French, Arabic) will display properly with either method of getting the text to the control. I thought that the control might not have the correct font loaded when I call SetWindowText. (Perhaps Cut&Paste somehow selected the font for me. Yes, I am ignoring the fact that the other exotic languages worked with SetWindowText.) Therefore I created a font (CreateFontIndirect with "Khmer OS System") and used CWnd::SetFont for the RichEdit before calling SetWindowText. This did not work. Having this one language fail seems to be odd because I did nothing special to make the others work. Therefore there is not much more I can offer about what I am doing or not doing. Can someone suggest an explanation of what might be failing? Is this Cambodian language not fully supported in Windows? Thanks
From: Mihai N. on 9 Dec 2009 01:22 > I have a CRichEditCtrl in a Unicode application that will not display Khmer > when I use SetWindowText but will display it when the same text is pasted > from a Word document. Sounds like this: http://www.mihai-nita.net/article.php?artID=20050709b > Many other languages (e.g. Japanese, Chinese, French, > Arabic) will display properly with either method of getting the text to the > control. But this part is weird. The explanation above would not allow for Chinese/Japanese/Arabic. So my second guess: bad font. Chinese, Japanese, Arabic (and others) are "fixed" by font fallback magic. Khmer might not be the case (depends on the Windows version, Win 7 is ok). You can use this http://www.mihai-nita.net/article.php?artID=charmapex to jump (Ctrl+J) to the Khmer block and see if you get characters in black (the font has the char), red (font fallback) or squares (missing glyph, no fallback). Windows 7 is the first one officially supporting Khmer ("official" means font, font fallback, keyboard, locale information). > and used CWnd::SetFont for the RichEdit before calling > SetWindowText. This did not work. If you set the font it should work. What was the result? Squares? Question marks? Junk? > Having this one language fail seems to be odd because I did nothing special > to make the others work. The font linking/substitution/fallback/magic done by the OS is not equal for all languages. And it can only happen to system fonts. If you install a "Khmer OS System" that is not used by the OS for fallback. > Therefore there is not much more I can offer about > what I am doing or not doing. What was the result when you set the font? Squares? Question marks? Junk? If you select the text in the RichEdit control and paste it in Notepad, and/or Word (direct, and paste special - plain text), and set the font to "Khmer OS System", does it look ok? -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: andrew on 9 Dec 2009 22:10 I took a look at the first link you suggested. You are right it does not apply. All .RC references use the Unicode version of the control. I also tried the program in the second link - a nifty littl tool. For me the Khmer page showed Red squares - "no fallback". The Khmer fonts that I have were downloaded from a site the promotes Khmer. I have : Khmer OS (True Type) Khmer OS Fasthand (True Type) Khmer OS Freehand (True Type) Khmer OS Muol (True Type) Khmer OS System (True Type) Khmer OT (True Type) Limon S1 (True Type) The problem could very well be a font issue since these did not come from Microsoft - I am running Windows XP. After calling SetFont, and even before, the RichEdit showed what looked like thick pipe ('|') characters for all Khmer characters. I am sorry but I cannot get Copy to work from my RichEdit. This may be another problem that may just be a style setting. However I do save the text in the control (via GetWindowText into a Unicode buffer) to a Unicode text file. What appears as pipes in the RichEdit actually is saved correctly and displays as Khmer in Word. So the Unicode data is preserved by the control but just not displayed properly. Thank you for your suggestions. I had no idea that there was something like "font fallback magic". This is something to think about. I have asked to have Windows 7 installed on a machine. When this is done I will try the program on it. If it works we will just have to say that full Khmer support comes only when the program runs under Windows 7. Thanks again. "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message news:Xns9CDBE38CAC5DCMihaiN(a)207.46.248.16... >> I have a CRichEditCtrl in a Unicode application that will not display >> Khmer >> when I use SetWindowText but will display it when the same text is pasted >> from a Word document. > > Sounds like this: > http://www.mihai-nita.net/article.php?artID=20050709b > >> Many other languages (e.g. Japanese, Chinese, French, >> Arabic) will display properly with either method of getting the text to >> the >> control. > > But this part is weird. The explanation above would not allow for > Chinese/Japanese/Arabic. > So my second guess: bad font. > Chinese, Japanese, Arabic (and others) are "fixed" by font fallback magic. > Khmer might not be the case (depends on the Windows version, Win 7 is ok). > > You can use this http://www.mihai-nita.net/article.php?artID=charmapex to > jump (Ctrl+J) to the Khmer block and see if you get characters in black > (the font has the char), red (font fallback) or squares (missing glyph, > no fallback). > > Windows 7 is the first one officially supporting Khmer > ("official" means font, font fallback, keyboard, locale information). > > >> and used CWnd::SetFont for the RichEdit before calling >> SetWindowText. This did not work. > > If you set the font it should work. > What was the result? Squares? Question marks? Junk? > > >> Having this one language fail seems to be odd because I did nothing >> special >> to make the others work. > > The font linking/substitution/fallback/magic done by the OS is not equal > for > all languages. And it can only happen to system fonts. > If you install a "Khmer OS System" that is not used by the OS for > fallback. > > >> Therefore there is not much more I can offer about >> what I am doing or not doing. > > What was the result when you set the font? Squares? Question marks? Junk? > If you select the text in the RichEdit control and paste it in Notepad, > and/or Word (direct, and paste special - plain text), and set the font > to "Khmer OS System", does it look ok? > > > > -- > Mihai Nita [Microsoft MVP, Visual C++] > http://www.mihai-nita.net > ------------------------------------------ > Replace _year_ with _ to get the real email >
From: Joseph M. Newcomer on 9 Dec 2009 23:29 See below... On Wed, 9 Dec 2009 22:10:39 -0500, "andrew" <thegroup(a)microsoft.com> wrote: >I took a look at the first link you suggested. You are right it does not >apply. All .RC references use the Unicode version of the control. I also >tried the program in the second link - a nifty littl tool. For me the Khmer >page showed Red squares - "no fallback". > >The Khmer fonts that I have were downloaded from a site the promotes Khmer. >I have : >Khmer OS (True Type) >Khmer OS Fasthand (True Type) >Khmer OS Freehand (True Type) >Khmer OS Muol (True Type) >Khmer OS System (True Type) >Khmer OT (True Type) >Limon S1 (True Type) > >The problem could very well be a font issue since these did not come from >Microsoft - I am running Windows XP. > >After calling SetFont, and even before, the RichEdit showed what looked like >thick pipe ('|') characters for all Khmer characters. I am sorry but I >cannot get Copy to work from my RichEdit. This may be another problem that >may just be a style setting. However I do save the text in the control (via >GetWindowText into a Unicode buffer) to a Unicode text file. What appears >as pipes in the RichEdit actually is saved correctly and displays as Khmer >in Word. So the Unicode data is preserved by the control but just not >displayed properly. **** I found that I had to provide my own right-click menu item, and send the WM_COPY message to the rich edit control myself. In addition, if you are using the Edit menu item, you usually have to handle the ID_EDIT_COPY message (and its update) in the view that holds the rich edit, and the command message has to send a WM_COPY message to the edit control itself. Usually, although the control may not display the characters properly, if you copy and then paste into a Unicode-based app, you will get the correct Unicode values in the paste. For the update handlers, I usually implement something that first determines if the control with the focus is an edit control (regular EDIT, Rich Edit, etc.) and then add the following code: check for CF_TEXT and/or CF_UNICODETEXT and only enable Paste if something valid is found (for rich edit, you might want to allow pasting images so that takes some additional checking) For a rich edit, you can EnumClipboardFormats and use the EM_CANPASTE message to determine if any of them are pastable; if any one is, then you enable Paste If the control is marked ReadOnly, do not enable Cut or Paste If the selection is empty, do not enable Cut or Copy It gets a little tricky if your rich edit control has protected fields within a highlighted region, and I punted that problem the last time I used them by simply disallowing copy, cut or paste if the highlighted area overlapped a protected region joe ***** > >Thank you for your suggestions. I had no idea that there was something like >"font fallback magic". This is something to think about. I have asked to >have Windows 7 installed on a machine. When this is done I will try the >program on it. If it works we will just have to say that full Khmer support >comes only when the program runs under Windows 7. > >Thanks again. > > >"Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message >news:Xns9CDBE38CAC5DCMihaiN(a)207.46.248.16... >>> I have a CRichEditCtrl in a Unicode application that will not display >>> Khmer >>> when I use SetWindowText but will display it when the same text is pasted >>> from a Word document. >> >> Sounds like this: >> http://www.mihai-nita.net/article.php?artID=20050709b >> >>> Many other languages (e.g. Japanese, Chinese, French, >>> Arabic) will display properly with either method of getting the text to >>> the >>> control. >> >> But this part is weird. The explanation above would not allow for >> Chinese/Japanese/Arabic. >> So my second guess: bad font. >> Chinese, Japanese, Arabic (and others) are "fixed" by font fallback magic. >> Khmer might not be the case (depends on the Windows version, Win 7 is ok). >> >> You can use this http://www.mihai-nita.net/article.php?artID=charmapex to >> jump (Ctrl+J) to the Khmer block and see if you get characters in black >> (the font has the char), red (font fallback) or squares (missing glyph, >> no fallback). >> >> Windows 7 is the first one officially supporting Khmer >> ("official" means font, font fallback, keyboard, locale information). >> >> >>> and used CWnd::SetFont for the RichEdit before calling >>> SetWindowText. This did not work. >> >> If you set the font it should work. >> What was the result? Squares? Question marks? Junk? >> >> >>> Having this one language fail seems to be odd because I did nothing >>> special >>> to make the others work. >> >> The font linking/substitution/fallback/magic done by the OS is not equal >> for >> all languages. And it can only happen to system fonts. >> If you install a "Khmer OS System" that is not used by the OS for >> fallback. >> >> >>> Therefore there is not much more I can offer about >>> what I am doing or not doing. >> >> What was the result when you set the font? Squares? Question marks? Junk? >> If you select the text in the RichEdit control and paste it in Notepad, >> and/or Word (direct, and paste special - plain text), and set the font >> to "Khmer OS System", does it look ok? >> >> >> >> -- >> Mihai Nita [Microsoft MVP, Visual C++] >> http://www.mihai-nita.net >> ------------------------------------------ >> Replace _year_ with _ to get the real email >> > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Mihai N. on 10 Dec 2009 01:27
Between this: > After calling SetFont, and even before, the RichEdit showed what looked > like thick pipe ('|') characters for all Khmer characters. And this: > However I do save the text in the control (via > GetWindowText into a Unicode buffer) to a Unicode text file. What appears > as pipes in the RichEdit actually is saved correctly and displays as Khmer > in Word. So the Unicode data is preserved by the control but just not > displayed properly. I am pretty sure the font is not set properly. > Thank you for your suggestions. I had no idea that there was something > like "font fallback magic". This is something to think about. Sure, the real name is not "font fallback magic" :-) Windows tries hard to select a font that can display the text. But there is no such thing as "Windows", there are various parts working separately, sometimes they conflict a bit. Each part has it's own mechanism and sometimes with a different name. There are logical fonts, and font mapping, and font substitution, and font linking, and font fallback. Some stuff hapen in GDI, some in Uniscribe, some by MLAng, some in the RichEdit control, Word add it's own smarts. So it is tough to say who is doing what if all you see is the final result. Here are some great blog entries: What about logical fonts? (with tons of other links from there) http://blogs.msdn.com/michkap/archive/2006/03/18/554308.aspx Font Linking vs. Font Fallback http://blogs.msdn.com/michkap/archive/2005/10/01/476022.aspx Font substitution and linking #1 http://blogs.msdn.com/michkap/archive/2005/03/20/399322.aspx http://blogs.msdn.com/michkap/archive/2005/05/16/417711.aspx About Khmer: http://blogs.msdn.com/michkap/archive/2008/12/03/9168086.aspx But overall things "just work" and they got better and better from a version of Windows to the next one. But for Khmer, Win7 is definitely the first one where it is officialy supported. Might (kind of) work with older versions, but no promises. -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email |