views:

526

answers:

3

I have written a DLL which exports a function that creates a window using RegisterClassExW and CreateWindowExW. Every message is retrieved via

GetMessageW(&msg, wnd_handle, 0, 0);
TranslateMessage(&msg);
DispatchMessageW(&msg);

Also there is a program which loads the DLL and calls the function.

Despite the Unicode window creation method, the wParam in the WM_CHAR message always contains ASCII characters, even if I type some non-ASCII symbols or use Alt+(code). Instead of UTF-16, the wParam contains some ASCII character between 'A' and 'z'. The WndProc is a static function inside the DLL.

The problem doesn't occur when all the window-related code is inside one program.

Is there a way to always have Unicode WM_CHAR messages inside the DLL's window?

A: 

I am not 100% sure, but it might help:

Take a look to the settings of the project where you implement the code that calls the DLL functions. Make sure that the character set is UNICODE as well, and not multibyte:

(go to Project Properties, then to General section, and put Character Set option to "Use Unicode Character Set"). I was assuming that you're using Visual Studio 2003 or later.

Cătălin Pitiș
The settings are set to Unicode. The _UNICODE preprocessor directive is also set.
+1  A: 

Your approach seems like it should work.

Is it possible that you're calling the ANSI DefWindowProc instead of the wide version? That would translate a WM_UNICHAR into ANSI WM_CHAR messages. Maybe that would explain what you're seeing.

As an experiment, I'd handle the WM_UNICHAR messages directly, and see what the data looks like at that point.

Adrian McCarthy
+1  A: 

the problem was in the message retrieval process. I used GetMessage() with the handle of my window instead of just 0, GetMessageW(&msg, wnd_handle, 0, 0) instead of GetMessageW(&msg, 0, 0, 0).
In this way, the WM_INPUTLANGCHANGEREQUEST messages were swallowed and the locale remained English.