Prev: MFC Dialog - Menu
Next: New utf8string design may make UTF-8 the superior encoding
From: Steve Jones on 17 May 2010 08:53
Thanks for all your comments. I am getting closer to the solution but still
not quite there.

As an experiment, I created a small test UNICODE MFC project with a CEdit
control and a CStatic control, and pasted some Japanese characters into the
CEdit control. The program then reads the CEdit contents (wide) and converts
the string to UTF8 and then back to UNICODE again (using WideCharToMultiByte
and MultiByteToWideChar), and then sets the CStatic control to display the
final UNICODE string using CMyStatic::SetWindowTextW()

This works fine - the Japanese characters show correctly in the CStatic
control. Great.

I then tried to add MultiByteToWideChar() and CMyStatic::SetWindowTextW() to
the actual program that I'm working on (project settings are MBCS). It
failed to compile saying that CStatic did mot have the method
SetWIndowTextW(), so I used the Win32 equivalent:

::SetWindowTextW(mystatic.GetSafeHwnd(), widestring)

This compiled OK, and the widestring parameter is displayed with the correct
Japanese characters in the debugger. But the actual static control displays
lots of "?" characters where the japanese characters should be.

I can't see much difference between the test program and the "real" program
except that one has UNICODE and the other has MBCS in its project settings.
Is there anything else I need to do to get the Japanese characters displayed
correctly?

From: David Lowndes on 17 May 2010 09:15
>This compiled OK, and the widestring parameter is displayed with the correct
>Japanese characters in the debugger. But the actual static control displays
>lots of "?" characters where the japanese characters should be.

Sounds like a wide->multibyte conversion has occurred somewhere - or
not using the same font.

>I can't see much difference between the test program and the "real" program
>except that one has UNICODE and the other has MBCS in its project settings.
>Is there anything else I need to do to get the Japanese characters displayed
>correctly?

Have a look at the IsWindowUnicode documentation remarks - that might
explain what's going on by trying to use a unicode Windows message in
an MBCS application.

Dave
From: Joseph M. Newcomer on 17 May 2010 12:15
See below...
On Mon, 17 May 2010 13:53:30 +0100, "Steve Jones" <nospam(a)devnull.com> wrote:

>Thanks for all your comments. I am getting closer to the solution but still
>not quite there.
>
>As an experiment, I created a small test UNICODE MFC project with a CEdit
>control and a CStatic control, and pasted some Japanese characters into the
>CEdit control. The program then reads the CEdit contents (wide) and converts
>the string to UTF8 and then back to UNICODE again (using WideCharToMultiByte
>and MultiByteToWideChar), and then sets the CStatic control to display the
>final UNICODE string using CMyStatic::SetWindowTextW()
>
>This works fine - the Japanese characters show correctly in the CStatic
>control. Great.
>
>I then tried to add MultiByteToWideChar() and CMyStatic::SetWindowTextW() to
>the actual program that I'm working on (project settings are MBCS). It
>failed to compile saying that CStatic did mot have the method
>SetWIndowTextW(), so I used the Win32 equivalent:
>
>::SetWindowTextW(mystatic.GetSafeHwnd(), widestring)
>
>This compiled OK, and the widestring parameter is displayed with the correct
>Japanese characters in the debugger. But the actual static control displays
>lots of "?" characters where the japanese characters should be.
>
>I can't see much difference between the test program and the "real" program
>except that one has UNICODE and the other has MBCS in its project settings.
>Is there anything else I need to do to get the Japanese characters displayed
>correctly?
****
I would suspect the problem is that a Unicode app loads the controls with Unicode-aware
fonts and an ANSI app does not do this. It is important that you have the correct font
set in the control, and doing this from an ANSI app may also mean you have to locate and
load a Unicode font, or at least one that has glyphs for your locale.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Steve Jones on 17 May 2010 13:26

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:lpq2v5t6odeb5jrcq0s9a66fcdi53cru96(a)4ax.com...
> I would suspect the problem is that a Unicode app loads the controls with
> Unicode-aware
> fonts and an ANSI app does not do this. It is important that you have the
> correct font
> set in the control, and doing this from an ANSI app may also mean you have
> to locate and
> load a Unicode font, or at least one that has glyphs for your locale.

Thanks. That does seem to be the case. I have managed to solve the problem
by creating a new control using ::RegisterClassExW() and
::CreateWindowExW(), and setting its text with ::SetWindowTextW(hwnd,
mywidestring). I also attached it to a CWnd for convenience - it seems that
ANSI messages are automatically converted to UNICODE messages so it seems OK
to just use generic CWnd function names rather than the W-prefixed ones
which would not compile in an ANSI program.

I used CWnd::SetFont() to set its font to be the same as another existing
ANSI CStatic. The japanese text seems now to be displayed OK.

The text to be displayed could in fact be in any language and there is no
way of knowing what that is - the program would just get presented with a
UTF8 string. So I would really need a high degree of confidence that the
text in whatever language would be displayed correctly.

How can I know what font should be loaded based simply on the contents of
the UTF8 string?

From: David Lowndes on 17 May 2010 13:41
>Have a look at the IsWindowUnicode documentation remarks - that might
>explain what's going on by trying to use a unicode Windows message in
>an MBCS application.

I've just tried a test and I'm fairly certain that the fact that the
window has been registered as MBCS is the issue you're seeing.

Building the project as Unicode would be the best solution.

Dave
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: MFC Dialog - Menu
Next: New utf8string design may make UTF-8 the superior encoding