2006-02-06 12:37:10 UTC
having lately. It consists of a main application (ANSI) and a Unicode
DLL. The main app is an app-wizard generated dialog based application
that creates a child Unicode dialog using the Unicode DLL. Both app
and the DLL use shared MFC.
When app starts, two edit controls are displayed. One is ANSI hosted
on the main app dialog and the other is Unicode hosted in the child
In order for PreTranslateMessage mechanism to work in the Unicode DLL,
the main app calls DLL's TranslateAccelerator function which calls
AfxPreTranslateMessage in the context of the Unicode DLL.
Now, activate IME and enter some, say, Japanese characters in the ANSI
edit box. If running Japanese regional settings, you will get what you
typed properly. If you do the same for the other (Unicode) edit box,
you will get garbage.
If you just comment out the TranslateAccelerator, even the Unicode
edit box will do just fine.
But I really need that TranslateAccelerator because I need the
PreTranslateMessage mechanism in both the app and the DLL.
I have narrowed the problem down to the WM_CHAR message which can
contain either a MBCS or a Unicode character. If TranslateAccelerator
is commented out, PreTranslateMessage does not call IsDialogMessageW
and the message is dispatched by DispatchMessageA of the main app's
message loop which recognizes that the target window is Unicode and
does a proper conversion.
On the other hand, if TranslateAccelerator is in place,
IsDialogMessageW is called at one point. It assumes that WM_CHAR is
already Unicode and does no translation. Therefore, the Unicode edit
box gets a MBCS WM_CHAR, treats it as Unicode character and inserts
How does one proceed with mixed ANSI/Unicode windows in a single
application and still have the PreTranslateMessage mechanism in place
Any help or suggestions is highly appreciated!