Russian input in ImGuiInputText

[or75]

Fix in ImGui_ImplWin32_WndProcHandler:

without fix:

use arial windows font:

???

[ocornut]

The result and need for fix may depends on whether the application was compiled in Unicode vs MB mode.

Could you try both modes, with and without the fix?

[or75]

Use dll (MB same):

unicode without fix:

unicode fix:

[ocornut]

If I compile my application in Unicode I don't need your fix:

io.Fonts->AddFontFromFileTTF("c:\\Windows\\Fonts\\segoeui.ttf", 18.0f, NULL, io.Fonts->GetGlyphRangesCyrillic());

Pressing here:

I am getting:

So this only affect programs compiled in multi-byte mode.
Will investigate.

[or75]

without fix imgui 1.88 use dll (WTF):

[or75]

use exe without fix (example_win32_directx9) -> working:

multibyte is bug:

[ocornut]

I can't read your language so I don't know if your copy of imgui_impl_win32 is compiled in Unicode or MB mode.

Before fix:

imgui_impl_win32 unicode:   OK
imgui_impl_win32 mbcs: not OK
imgui_impl_glfw  unicode:   OK
imgui_impl_glfw  mbcs: OK
imgui_impl_sdl   unicode:   OK
imgui_impl_sdl   mbcs: OK

So it is indeed a bug in imgui_impl_win32 backend.

But you should simply compile imgui_impl_win32 with Unicode enabled perhaps?
You should register your window class using RegisterClassW() or compile the code calling it in Unicode mode and call RegisterClass().

Your fix breaks when compiled with Unicode.
So let's assuming we change it to

    case WM_CHAR:
#ifdef _UNICODE
        // You can also use ToAscii()+GetKeyboardState() to retrieve characters.
        if (wParam > 0 && wParam < 0x10000)
            io.AddInputCharacterUTF16((unsigned short)wParam);
#else
        wchar_t wch;;
        ::MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, (char*)&wParam, 1, &wch, 1);
        io.AddInputCharacter(wch);
#endif
        return 0;

I have two issues:

• I don't know if your conversion is correct in all systems and cases/locals. In fact, it is NOT correct on my system right now.
• I don't well understand use of surrogate (added by Full Unicode Support #2541 Refreshed full Unicode support patch #2815)

Looking at GLFW/SDL etc things are confusing.

• There is a WM_IME_CHAR message.
• There is a WM_UNICHAR message.
• Also notice Non-unicode IME support #3653 (uses WM_IME_CHAR).

SDL does:

    case WM_UNICHAR:
        if (wParam == UNICODE_NOCHAR) {
            returnCode = 1;
        } else {
            char text[5];
            if (WIN_ConvertUTF32toUTF8((UINT32)wParam, text)) {
                SDL_SendKeyboardText(text);
            }
            returnCode = 0;
        }
        break;

    case WM_CHAR:
        /* When a user enters a Unicode code point defined in the Basic Multilingual Plane, Windows sends a WM_CHAR
           message with the code point encoded as UTF-16. When a user enters a Unicode code point from a Supplementary
           Plane, Windows sends the code point in two separate WM_CHAR messages: The first message includes the UTF-16
           High Surrogate and the second the UTF-16 Low Surrogate. The High and Low Surrogates cannot be individually
           converted to valid UTF-8, therefore, we must save the High Surrogate from the first WM_CHAR message and
           concatenate it with the Low Surrogate from the second WM_CHAR message. At that point, we have a valid
           UTF-16 surrogate pair ready to re-encode as UTF-8. */
        if (IS_HIGH_SURROGATE(wParam)) {
            data->high_surrogate = (WCHAR)wParam;
        } else if (IS_SURROGATE_PAIR(data->high_surrogate, wParam)) {
            /* The code point is in a Supplementary Plane.
               Here wParam is the Low Surrogate. */
            char text[5];
            if (WIN_ConvertUTF16toUTF8((UINT32)data->high_surrogate, (UINT32)wParam, text)) {
                SDL_SendKeyboardText(text);
            }
            data->high_surrogate = 0;
        } else {
            /* The code point is in the Basic Multilingual Plane.
               It's numerically equal to UTF-32. */
            char text[5];
            if (WIN_ConvertUTF32toUTF8((UINT32)wParam, text)) {
                SDL_SendKeyboardText(text);
            }
        }
        returnCode = 0;
        break;

GLFW does:

        case WM_CHAR:
        case WM_SYSCHAR:
        case WM_UNICHAR:
        {
            const GLFWbool plain = (uMsg != WM_SYSCHAR);

            if (uMsg == WM_UNICHAR && wParam == UNICODE_NOCHAR)
            {
                // WM_UNICHAR is not sent by Windows, but is sent by some
                // third-party input method engine
                // Returning TRUE here announces support for this message
                return TRUE;
            }

            _glfwInputChar(window, (unsigned int) wParam, getKeyMods(), plain);

            if (uMsg == WM_SYSCHAR && window->win32.keymenu)
                break;

            return 0;
        }
[...]
void _glfwInputChar(_GLFWwindow* window, unsigned int codepoint, int mods, GLFWbool plain)
{
    if (codepoint < 32 || (codepoint > 126 && codepoint < 160))
        return;

     [...] // Omitting Key Mods related code
    if (!window->lockKeyMods)
        mods &= ~(GLFW_MOD_CAPS_LOCK | GLFW_MOD_NUM_LOCK);
    if (plain)
    {
        if (window->callbacks.character)
            window->callbacks.character((GLFWwindow*) window, codepoint);
    }
}

Notes:

• (1) In both Unicode or MBCS compile mode, I can't seem to get WM_UNICHAR emitted.
• (2) GLFW doesn't seem to do any specific processing.

Given:

Unicode Character “ô” (U+00F4)
Unicode Character “ф” (U+0444)

Debugging our Win32+DX11 test app in MBCS mode:

• I get WM_CHAR with 0xF4
• Passing 0xF4 to MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, ...) returns 0xF4.

Debugging GLFW in MBCS mode:

• I get WM_CHAR with 0x0444

https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-char

The WM_CHAR message uses UTF-16 (16-bit Unicode Transformation Format) code units in its wParam if the Unicode version of the RegisterClass function was used to register the window class.

GLFW calls RegisterClassW(). Our test application calls RegisterClass() which is redirected to RegisterClassA() or RegisterClassW(). SDL also enforces _UNICODE and therefore calls RegisterClassW() always.
So it's not something to do with _UNICODE define but with this registration.

Does this works for you?

case WM_CHAR:
    if (::IsWindowUnicode(hwnd))
    {
        // You can also use ToAscii()+GetKeyboardState() to retrieve characters.
        if (wParam > 0 && wParam < 0x10000)
            io.AddInputCharacterUTF16((unsigned short)wParam);
    }
    else
    {
        wchar_t wch = 0;
        ::MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, (char*)&wParam, 1, &wch, 1);
        io.AddInputCharacter(wch);
    }
    return 0;

I can't get it to work but presumably using RegisterClassA() means you depend on current system codepage.
I can commit this partial fix but you'd better call RegisterClassW().

Благодарю вас!

[or75]

working, thanks

case WM_CHAR:
    if (::IsWindowUnicode(hwnd))
    {
        // You can also use ToAscii()+GetKeyboardState() to retrieve characters.
        if (wParam > 0 && wParam < 0x10000)
            io.AddInputCharacterUTF16((unsigned short)wParam);
    }
    else
    {
        wchar_t wch = 0;
        ::MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, (char*)&wParam, 1, &wch, 1);
        io.AddInputCharacter(wch);
    }
    return 0;

[ocornut]

Pushed a229a7f (make examples always use Unicode) + 0a7054c (fallback for your case).