Reputation: 276
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?
Upvotes: 2
Views: 2780
Reputation: 276
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.
Upvotes: 4
Reputation: 47954
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.
Upvotes: 2
Reputation: 14341
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.
Upvotes: 0