WinAPI: How to process keyboard input in custom edit control

So i'm creating my own edit control (multi-line textbox) in C++ using the windows API. It's going pretty well, but i'm a bit confused about one thing.

First off, the control is being built to be able to handle unicode and all input will be converted to unicode. In other words, all input will be stored as wchar_t.

What i'm confused about is which message to process for keyboard input. MSDN has the following window notifications:

WM_CHAR

WM_KEYDOWN

WM_UNICHAR

And others, but i believe it's one of these three that i need to process. My guess would be WM_UNICHAR, but the documentation is a bit unclear about it. Also, upon looking over the VKcodes, i saw this:

VK_PACKET

0xE7

Used to pass Unicode characters as if they were keystrokes. The VK_PACKET key is the low word of a 32-bit Virtual Key value used for non-keyboard input methods. For more information, see Remark in KEYBDINPUT, SendInput, WM_KEYDOWN, and WM_KEYUP.

Sorry if it's a silly question, but i just wa开发者_JAVA技巧nt to be sure about this.

If your control is created as a unicode window (using CreateWindowW) then in WM_CHAR you will get wide char out of the box.

If you want to provide non-unicode version of your control then you need to handle WM_INPUTLANGCHANGE, something like this:

case WM_INPUTLANGCHANGE:
{
              HKL NewInputLocale = (HKL) lParam ;
              g_InputCodePage = LangToCodePage( LOWORD(NewInputLocale) ) ; 
}

And so your WM_CHAR handler should look like:

 case WM_CHAR:
     {
        unsigned char c = (byte)wParam;
        if(!::IsWindowUnicode(hwnd))
          MultiByteToWideChar(g_InputCodePage , 0, (LPCSTR) &c, 1, (LPWSTR) &wParam, 1) ;
     }

And don't forget about WM_IME_CHAR and friends. And yet about RTL input.

WM_KEYDOWN is sent to the window with the focus when a non-system key has been pressed. When the message is translated by the TranslateMessage function, a WM_CHAR message is sent to the window. WM_CHAR uses UTF-16. WM_UNICHAR is similat to WM_CHAR, except that it uses UTF-32. It's purpose is to send/post Unicode characters to ANSI windows. If the window is ANSI (created with CreateWindowA), when WM_CHAR is generated. If it is Unicode (created with CreateWindowW) then WM_UNICHAR is generated. So your control should probably handle both.

Also see this discussion Why is my WM_UNICHAR handler never called?.