Change DefWindowProc to DefWindowProcW for Unicode by ulhc · Pull Request #9099 · ocornut/imgui

ulhc · 2025-11-28T14:57:31Z

The RegisterClassExW referenced at ImGui_ImplWin32_InitMultiViewportSupport is Unicode, while the DefWindowProc referenced at ImGui_ImplWin32_WndProcHandler_PlatformWindow will cause encoding errors when inputting double-byte characters if the character set is multi-byte.

DefWindowProcA:

DefWindowProcW:

Handle WM_IME_CHAR message for input character processing.

ocornut · 2025-12-01T12:16:36Z

Thank you for your PR.
I can repro the reported problem and indeed fix it by using DefWindowProcW().

However, it doesn't seem to require the WM_IME_CHAR handler.
Can you clarify what the WM_IME_CHAR handler is for?

Linking to #3653, #5961

ulhc · 2025-12-01T14:45:21Z

However, it doesn't seem to require the WM_IME_CHAR handler. Can you clarify what the WM_IME_CHAR handler is for?

Sorry, I didn't describe it clearly.

Changing DefWindowProc to DefWindowProcW in ImGui_ImplWin32_WndProcHandler_PlatformWindow method in imgui_impl_win32.cpp can only solve the problem of platform window input created by imgui.

WM_IME_CHAR mainly solves the problem of user-created main platform window input (compatible with RegisterClassA or RegisterClassW).

ocornut · 2025-12-01T14:46:42Z

I don't understand, could you clarify ?

ulhc · 2025-12-01T15:04:46Z

I don't understand, could you clarify ?

Sorry, my English is not very good.

WM_IME_CHAR primarily addresses input issues when merging an ImGui window into a user window.

A:

B:

ocornut · 2025-12-01T15:09:39Z

Sorry, my English is not very good.

Your english is not an issue here, don't worry :)

But:

" WM_IME_CHAR primarily addresses input issues when merging an ImGui window into a user window. "

I don't know what a "merge an ImGui Window" or "a user window" means, it's ambiguous.
Please stick to raw facts and provide a step by step explanation.

You are showing a video where the inputs happens over "Dear ImGui DirectX11 Example", is that the exact code provided in examples/example_win32_directx11/main.cpp ? Because that window is created with CreateWindowW(), and it works for me without the WM_IME_CHAR. How did you build it?

ulhc · 2025-12-01T15:14:45Z

You are showing a video where the inputs happens over "Dear ImGui DirectX11 Example", is that the exact code provided in examples/example_win32_directx11/main.cpp ? Because that window is created with CreateWindowW(), and it works for me without the WM_IME_CHAR. How did you build it?

I changed RegisterClassExW to RegisterClassExA in main.cpp because most of my projects use RegisterClassEx, which automatically selects based on _UNICODE, and I wanted to be compatible with both A and W.

ocornut · 2025-12-01T15:17:56Z

Thanks, I understand and I can recreate the issue now.

This solves the same as #3653 but differently.

[Q1] Can you explain the difference between your coed and #3653 ? (I prefer yours, but I wonder why #3653 uses WM_IME_COMPOSITION).

ocornut · 2025-12-01T15:29:19Z

[Q2] Why are you doing

::MultiByteToWideChar(bd->KeyboardCodePage, MB_PRECOMPOSED, (char*)&ch, sizeof(ch), &wch, 1);

sizeof(ch) == 2
and our existing WM_CHAR handler does:

::MultiByteToWideChar(bd->KeyboardCodePage, MB_PRECOMPOSED, (char*)&wParam, 1, &wch, 1);

added by 0a7054c. Wasn't this patch already supposed to fix this?

Also see #1807 (comment).

ulhc · 2025-12-01T15:31:02Z

Thanks, I understand and I can recreate the issue now.

This solves the same as #3653 but differently.

[Q1] Can you explain the difference between your coed and #3653 ? (I prefer yours, but I wonder why #3653 uses WM_IME_COMPOSITION).

After input is complete, WM_IME_COMPOSITION will trigger once with the entire character table, while WM_IME_CHAR is more like WM_CHAR, triggering for each character individually.

#3653 Cannot handle input of multiple consecutive characters.

ulhc · 2025-12-01T15:37:54Z

sizeof(ch) == 2 and our existing WM_CHAR handler does:

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

(RegisterClassA)DBCS: A single-byte or double-byte character value. For a double-byte character, (BYTE)(wParam >> 8) contains the lead byte. Note that the parentheses are necessary because the cast operator has higher precedence than the shift operator.

(RegisterClassW)Unicode: A Unicode character value.

or

::MultiByteToWideChar(bd->KeyboardCodePage, MB_PRECOMPOSED, (char*)&ch, 2, &wch, 1);

and our existing WM_CHAR handler does:

The wParam received in WM_CHAR is not a complete DBCS but a truncated one, so you need to concatenate it yourself.

ocornut · 2025-12-01T15:48:00Z

I need your help and a more careful exploration and explanation of every paths. This code is used by thousands of people.

[Q3] Was 0a7054c actually broken or unsufficient? If no, why. If yes, why didn't people notice?

[Q4] If I change every xxxW() calls in main.cpp to xxxx() + change build settings from Unicode to MBCS, then nothing works, while inputting e.g. 本 I only get 0x3F values in wParam in WM_IME_CHAR. For this to work I need main.cpp's WndProc to call DefWindowProcW() and NOT DefWindowProc(), is that expected?

ocornut · 2025-12-01T15:52:24Z

I guess what I want to understand most is Q3 the status of 0a7054c, what did it fix and/or break?

ulhc · 2025-12-01T16:01:33Z

I guess what I want to understand most is Q3 the status of 0a7054c, what did it fix and/or break?

It seems to have no effect; it simply processes the double-byte character as '??'.

…tting non-ASCII values to io.AddInputCharacter(). (#9099)

ulhc · 2025-12-01T16:04:38Z

[Q4] If I change every xxxW() calls in main.cpp to xxxx() + change build settings from Unicode to MBCS, then nothing works, while inputting e.g. 本 I only get 0x3F values in wParam in WM_IME_CHAR. For this to work I need main.cpp's WndProc to call DefWindowProcW() and NOT DefWindowProc(), is that expected?

Whether DefWindowProc is A or W should be determined by RegisterClassEx.

If WM_IME_CHAR is handled, then both A and W will be compatible.

ocornut · 2025-12-01T16:08:46Z

It seems to have no effect; it simply processes the double-byte character as '??'.

Then how come #5725 (comment) said "working!"

Whether DefWindowProc is A or W should be determined by RegisterClassEx.
If WM_IME_CHAR is handled, then both A and W will be compatible.

See my code, if I make app MBCS and remove all A/W suffix I only get 0x3F values in WM_IME_CHAR:
imgui-02c99d6-WIP 9099.patch

(Keyboard in japanese mode, inputting any Japanese text)

ocornut · 2025-12-01T16:22:34Z

Then how come #5725 (comment) said "working!"

I investigated and realized is is because local codepage mostly have 1 byte characters, so it worked for Cyrillic with Code_page_866.
The old code is useful and work at least for Cyrillic and many local codepages, but should use 2 instead of 1 byte.

ulhc · 2025-12-01T16:35:48Z

See my code, if I make app MBCS and remove all A/W suffix I only get 0x3F values in WM_IME_CHAR: imgui-02c99d6-WIP 9099.patch

(Keyboard in japanese mode, inputting any Japanese text)

I seem to be different from you.

I'm using a Chinese keyboard, and the result of typing 'の' is:
[01692] WM_IME_CHAR 0000A4CE
[01693] [io] Processed: Text: n (U+0000306E)

Using a Japanese keyboard, the result of typing 'あ' is:
[49707] WM_IME_CHAR 000000A4
[49707] WM_IME_CHAR 000000A2
[49708] [io] Processed: Text: d (U+0000FF64)
[49708] [io] Processed: Text: b (U+0000FF62)

ocornut · 2025-12-01T16:38:11Z

Just to confirm, is this with my patch over docking?
Are you building using MSVC .sln/.vsproj project or another way?

ocornut · 2025-12-01T16:46:22Z

I found an answer for it:
https://stackoverflow.com/a/77509342/4034925

"If your program registers by RegisterClassA() or RegisterClassExA(), the wParam of WM_IME_CHAR gets the particular encoding selected by the “language for non-Unicode programs” setting."

"When the “language for non-Unicode programs” is set to “English (United States)”, or any languages whose encoding does not cover the input, and a user enters Eastern Asian characters via an IME, the values in wParam of WM_IME_CHAR depend on how you register the class and how you handle the WM_IME_COMPOSITION message. If WM_IME_COMPOSITION is properly handled, and you register via RegisterClass[Ex]A(), the wParam gets the encoding of the IME. if you register via RegisterClass[Ex]W() the wParam gets the Unicode. Without proper handling of the WM_IME_COMPOSITION message, the wParam gets a “?” to indicate an error condition, regardless how you register the window class, by RegisterClass[Ex]A() or RegisterClass[Ex]W(). "

ocornut · 2025-12-01T17:12:50Z

(1) If I use this:

    case WM_IME_COMPOSITION:
    {
        // Handling WM_IME_COMPOSITION ensure that WM_IME_CHAR value is correct even for MBCS apps.
        // (see #9099, #3653 and https://stackoverflow.com/questions/77450354 topics) 
        IMGUI_DEBUG_LOG("WM_IME_COMPOSITION wParam %08X, lParam %08X\n", wParam, lParam);
        return ::DefWindowProcW(hwnd, msg, wParam, lParam);
    }
    case WM_IME_CHAR:
        if (::IsWindowUnicode(hwnd) == FALSE)
        {
            unsigned short ch = (unsigned short)wParam;
            if (::IsDBCSLeadByte(HIBYTE(wParam)))
                ch = MAKEWORD(HIBYTE(wParam), LOBYTE(wParam));

            wchar_t wch = 0;
            ::MultiByteToWideChar(bd->KeyboardCodePage, MB_PRECOMPOSED, (char*)&ch, sizeof(ch), &wch, 1);

            IMGUI_DEBUG_LOG("WM_IME_CHAR %08X -> %08X -> %08X\n", wParam, ch, wch);
            io.AddInputCharacterUTF16(wch);
            
            return 1;
        }
        return 0;

I get the correct WM_IME_CHAR value FOLLOWED by an incorrect WM_IME_CHAR ? value.

[07650] WM_IME_COMPOSITION wParam 00008882, lParam 000001B9
[07681] WM_IME_COMPOSITION wParam 0000D982, lParam 000001B9
[07686] WM_IME_COMPOSITION wParam 0000D982, lParam 000001B9
[07696] WM_IME_COMPOSITION wParam 0000D982, lParam 000001B9
[07707] WM_IME_COMPOSITION wParam 00007B96, lParam 000001B9
[07769] WM_IME_COMPOSITION wParam 00007B96, lParam 00001E00
[07769] WM_IME_CHAR 00007B96 -> 00007B96 -> 0000672C
[07769] WM_IME_CHAR 0000003F -> 0000003F -> 0000003F
[07770] [io] Processed: Text: '本' (U+0000672C) <---- GOOD
[07770] [io] Processed: Text: '?' (U+0000003F) <--- BAD
[07858] [io] Processed: MouseButton 0 Down (Mouse)
[07865] [io] Processed: MouseButton 0 Up (Mouse)

Do you get the same result?

(2) If I change handler to:

    case WM_IME_COMPOSITION:
    {
        // Handling WM_IME_COMPOSITION ensure that WM_IME_CHAR value is correct even for MBCS apps.
        // (see #9099, #3653 and https://stackoverflow.com/questions/77450354 topics) 
        IMGUI_DEBUG_LOG("WM_IME_COMPOSITION wParam %08X, lParam %08X\n", wParam, lParam);
        ::DefWindowProcW(hwnd, msg, wParam, lParam);
        return 1;
    }

+ WM_IME_CHAR handler, then I only get the correct WM_IME_CHAR message, but I worry this can interfere with app.

(3) This also seems to work for me:

    case WM_IME_COMPOSITION:
    {
        // Handling WM_IME_COMPOSITION ensure that WM_IME_CHAR value is correct even for MBCS apps.
        // (see #9099, #3653 and https://stackoverflow.com/questions/77450354 topics) 
        IMGUI_DEBUG_LOG("WM_IME_COMPOSITION wParam %08X, lParam %08X\n", wParam, lParam);
        LRESULT result = ::DefWindowProcW(hwnd, msg, wParam, lParam);
        return (lParam & GCS_RESULTSTR) ? 1 : result;
    }

+ WM_IME_CHAR handler.

Can you check all three on your system?

ocornut · 2025-12-01T17:57:32Z

(4)
I found an alternative simpler solution

Fix WM_CHAR's MultiByteToWideChar() call to use 2 == sizeof(wchar_t) instead of 1:

    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(bd->KeyboardCodePage, MB_PRECOMPOSED, (char*)&wParam, 2, &wch, 1);
            IMGUI_DEBUG_LOG("WM_CHAR %08X -> wch %08X\n", wParam, wch);
            io.AddInputCharacter(wch);
        }
        return 0;

And simply add handler:

    case WM_IME_COMPOSITION:
    {
        // Handling WM_IME_COMPOSITION ensure that WM_IME_CHAR value is correct even for MBCS apps.
        // (see #9099, #3653 and https://stackoverflow.com/questions/77450354 topics) 
        IMGUI_DEBUG_LOG("WM_IME_COMPOSITION wParam %08X, lParam %08X\n", wParam, lParam);
        LRESULT result = ::DefWindowProcW(hwnd, msg, wParam, lParam);
        return (lParam & GCS_RESULTSTR) ? 1 : result;
    }

No need to add WM_IME_CHAR handler.

Can you check if it works for you in all situations?

(Unfortunately there's no way to reach LR55 the author of that StackOverflow post, who might know more, since zealous SO admins are flagging answers attempts as "delete" because they want a new question, which ultimately will not reach that person)

ulhc · 2025-12-02T02:39:04Z

The result of typing the character '本' on my local computer:

(1) If I use this:

[01298] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01356] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01373] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01469] WM_IME_COMPOSITION wParam 0000B1BE, lParam 00001C00
[01469] WM_IME_CHAR 0000B1BE -> 0000BEB1 -> 0000672C
[01469] WM_IME_CHAR 0000B1BE -> 0000BEB1 -> 0000672C
[01470] [io] Processed: Text: , (U+0000672C)
[01470] [io] Processed: Text: , (U+0000672C)
It received 2 '本'

(2) If I change handler to:

[01178] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01197] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01211] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01333] WM_IME_COMPOSITION wParam 0000B1BE, lParam 00001C00
[01333] WM_CHAR 000000B1 -> wch 0000003F
[01333] WM_CHAR 000000BE -> wch 0000003F
[01334] [io] Processed: Text: ? (U+0000003F)
[01334] [io] Processed: Text: ? (U+0000003F)
It received 2 '??'

(3) This also seems to work for me:

[01095] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01136] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01145] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01261] WM_IME_COMPOSITION wParam 0000B1BE, lParam 00001C00
[01261] WM_CHAR 000000B1 -> wch 0000003F
[01261] WM_CHAR 000000BE -> wch 0000003F
[01262] [io] Processed: Text: ? (U+0000003F)
[01262] [io] Processed: Text: ? (U+0000003F)
Same result as the previous one

(4) I found an alternative simpler solution

[01395] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01415] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01429] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01485] WM_IME_COMPOSITION wParam 0000B1BE, lParam 00001C00
[01485] WM_CHAR 000000B1 -> wch 0000003F
[01485] WM_CHAR 000000BE -> wch 0000003F
[01486] [io] Processed: Text: ? (U+0000003F)
[01486] [io] Processed: Text: ? (U+0000003F)
Same result as the previous one

On my computer, it seems that only WM_IME_CHAR can receive a complete double-byte character (such as '本' == {BE, B1}, which is a complete double-byte character), while WM_CHAR will split them and then send them, sending B1 first and then BE, causing MultiByteToWideChar to fail to convert them into visible characters correctly.

ulhc · 2025-12-02T12:53:52Z

Or you can try the following code to see if it works (it works on my computer):

(1) I modified example (1)

    case WM_IME_COMPOSITION:
    {
        // Handling WM_IME_COMPOSITION ensure that WM_IME_CHAR value is correct even for MBCS apps.
        // (see #9099, #3653 and https://stackoverflow.com/questions/77450354 topics) 
        IMGUI_DEBUG_LOG("WM_IME_COMPOSITION wParam %08X, lParam %08X\n", wParam, lParam);
        LRESULT result = ::DefWindowProc(hwnd, msg, wParam, lParam);
        return (lParam & GCS_RESULTSTR) ? 1 : result;
    }
    case WM_IME_CHAR:
        if (::IsWindowUnicode(hwnd) == FALSE)
        {
            unsigned short ch = (unsigned short)wParam;
            if (::IsDBCSLeadByte(HIBYTE(wParam)))
                ch = MAKEWORD(HIBYTE(wParam), LOBYTE(wParam));

            wchar_t wch = 0;
            ::MultiByteToWideChar(bd->KeyboardCodePage, MB_PRECOMPOSED, (char*)&ch, sizeof(ch), &wch, 1);

            IMGUI_DEBUG_LOG("WM_IME_CHAR %08X -> %08X -> %08X\n", wParam, ch, wch);
            io.AddInputCharacterUTF16(wch);
            
            return 1;
        }
        return 0;

// [01568] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
// [01585] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
// [01677] WM_IME_COMPOSITION wParam 0000B1BE, lParam 00001C00
// [01677] WM_IME_CHAR 0000B1BE -> 0000BEB1 -> 0000672C
// [01678] [io] Processed: Text: , (U+0000672C)

(2)

    case WM_IME_COMPOSITION:
    {
        // Handling WM_IME_COMPOSITION ensure that WM_IME_CHAR value is correct even for MBCS apps.
        // (see #9099, #3653 and https://stackoverflow.com/questions/77450354 topics)
        if (lParam & GCS_RESULTSTR)
        {
            if (HIMC himc = ::ImmGetContext(hwnd))
            {
                ImVector<ImWchar16> result;
                LONG size = ::ImmGetCompositionStringW(himc, GCS_RESULTSTR, NULL, 0);
                if (size != IMM_ERROR_NODATA && size != IMM_ERROR_GENERAL && size > 0)
                {
                    result.resize(size / sizeof(ImWchar16));
                    ::ImmGetCompositionStringW(himc, GCS_RESULTSTR, result.Data, size);
                    for (const ImWchar16& wch : result)
                    {
                        IMGUI_DEBUG_LOG("WM_IME_COMPOSITION wParam %08X, wch %08X\n", wParam, wch);
                        io.AddInputCharacterUTF16(wch);
                    }
                }
                ::ImmReleaseContext(hwnd, himc);
                return result.empty() ? 0 : 1;
            }
        }
        return 0;
    }

// [01553] WM_IME_COMPOSITION wParam 0000B1BE,  wch 0000672C
// [01554] [io] Processed: Text: , (U+0000672C)

ocornut · 2025-12-03T10:38:41Z

For my (2) and (3) above did you keep the WM_IME_CHAR handler? Sorry my comment said "+ WM_IME_CHAR" but github markdown turned the + into a bullet point so it wasn't clear.

ocornut · 2025-12-03T10:45:07Z

Actually your (1) is the same as my (3) once you add WM_IME_CHAR, so you probably misunderstood my (2) and (3) and did not include the WM_IME_CHAR handler in your test.

I think we can go for my (3) == your (1).
But could you confirm that my (2) with WM_IME_CHAR handler also works? So we gather a maximum of data.

The reason I prefer to avoid using ImmGetCompositionStringW() is that it means we requires linking with imm32.lib. It's already linked by default by core imgui but can be disabled with IMGUI_DISABLE_WIN32_DEFAULT_IME_FUNCTIONS. Of course it's a little unlikely that someone would use imgui_impl_win32 backend with IMGUI_DISABLE_WIN32_DEFAULT_IME_FUNCTIONS, but it doesn't hurt supporting it.

ulhc · 2025-12-03T10:45:54Z

For my (2) and (3) above did you keep the WM_IME_CHAR handler? Sorry my comment said "+ WM_IME_CHAR" but github markdown turned the + into a bullet point so it wasn't clear.

No, I didn't. If WM_IME_CHAR is added, the output is:
(2)
[00651] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[00676] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[00810] WM_IME_COMPOSITION wParam 0000B1BE, lParam 00001C00
[00810] WM_IME_CHAR 0000B1BE -> 0000BEB1 -> 0000672C
[00811] [io] Processed: Text: , (U+0000672C)

(3)
[01052] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01105] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01130] WM_IME_COMPOSITION wParam 00000062, lParam 000001B8
[01268] WM_IME_COMPOSITION wParam 0000B1BE, lParam 00001C00
[01268] WM_IME_CHAR 0000B1BE -> 0000BEB1 -> 0000672C
[01269] [io] Processed: Text: , (U+0000672C)

ulhc · 2025-12-03T10:47:43Z

But could you confirm that my (2) with WM_IME_CHAR handler also works? So we gather a maximum of data.

Yes, they work properly after being added.

Add handling for WM_IME_COMPOSITION to ensure correct WM_IME_CHAR values in MBCS apps.

ulhc · 2025-12-03T11:26:52Z

@ocornut

I want to replace the following in imgui_impl_win32.cpp:

RegisterClassExW with RegisterClassEx;

CreateWindowExW with CreateWindowEx;

DefWindowProcW with DefWindowProc;

Are there any potential problems? I haven't found any issues in my tests so far.

…indowProcW() in order to support Unicode text inputs. (#9099, #3653, #5961)

ocornut · 2025-12-03T12:38:39Z

Are there any potential problems? I haven't found any issues in my tests so far.

That seem to undo your fist commit now merged as 962cc23
Wasn't this first commit intentional and needed even in MBCS mode?

…nt (should be no-op?). Amend 0a7054c (#5725, #1807, #471, #2815, #1060 + #9099, #3653, #5961)

…pport Unicode inputs on MBCS Windows. (#9099, #3653, #5961)

ocornut · 2025-12-03T12:42:41Z

I have now merged:

962cc23 in docking
87b1933 in master
d27dce5 in master
And master has been merged into Docking.

want to replace the following in imgui_impl_win32.cpp:
RegisterClassExW with RegisterClassEx;

I'm open to this in theory but we need carefully testing and it undo your first commit.
In practice I believe there's no benefit in bothering with this.

ocornut · 2025-12-03T12:44:13Z

Thanks for your help with this! I'm closing now but happy to discuss the last RegisterClassExW -> RegisterClassEx stuff if needed.

ulhc · 2025-12-03T12:47:04Z

I'm open to this in theory but we need carefully testing and it undo your first commit.
In practice I believe there's no benefit in bothering with this.

If WM_IME_CHAR is processed and the W suffix is removed from RegisterClassExW and CreateWindowExW, just leave it as is. Removing the W suffix, as you said, is meaningless.

Thanks a lot.

…tting non-ASCII values to io.AddInputCharacter(). (ocornut#9099)

…nt (should be no-op?). Amend 0a7054c (ocornut#5725, ocornut#1807, ocornut#471, ocornut#2815, ocornut#1060 + ocornut#9099, ocornut#3653, ocornut#5961)

…pport Unicode inputs on MBCS Windows. (ocornut#9099, ocornut#3653, ocornut#5961)

ulhc added 2 commits November 28, 2025 22:45

Change DefWindowProc to DefWindowProcW for Unicode

75b6b61

Add support for WM_IME_CHAR in Win32 backend

48e6557

Handle WM_IME_CHAR message for input character processing.

ocornut added backends ime labels Nov 28, 2025

ocornut added a commit that referenced this pull request Dec 1, 2025

Debug Log: fixed incorrectly printing characters in IO log when submi…

bfe1378

…tting non-ASCII values to io.AddInputCharacter(). (#9099)

ocornut mentioned this pull request Dec 1, 2025

Non-unicode IME support #3653

Closed

Handle WM_IME_COMPOSITION for MBCS support

80b6e51

Add handling for WM_IME_COMPOSITION to ensure correct WM_IME_CHAR values in MBCS apps.

Use TEXT macro for window class and title strings

20e9b6d

ocornut pushed a commit that referenced this pull request Dec 3, 2025

Backends: Win32: viewports created by backend direct messages to DefW…

962cc23

…indowProcW() in order to support Unicode text inputs. (#9099, #3653, #5961)

ocornut added a commit that referenced this pull request Dec 3, 2025

Backends: Win32: change param to MultiByteToWideChar() to be consiste…

87b1933

…nt (should be no-op?). Amend 0a7054c (#5725, #1807, #471, #2815, #1060 + #9099, #3653, #5961)

ocornut pushed a commit that referenced this pull request Dec 3, 2025

Backends: Win32: handle WM_IME_CHAR/WM_IME_COMPOSITION messages to su…

d27dce5

…pport Unicode inputs on MBCS Windows. (#9099, #3653, #5961)

ocornut closed this Dec 3, 2025

ulhc deleted the docking branch December 3, 2025 12:48

Intrets pushed a commit to Intrets/imgui that referenced this pull request Jan 1, 2026

Debug Log: fixed incorrectly printing characters in IO log when submi…

bb541ae

…tting non-ASCII values to io.AddInputCharacter(). (ocornut#9099)

Intrets pushed a commit to Intrets/imgui that referenced this pull request Jan 1, 2026

Backends: Win32: handle WM_IME_CHAR/WM_IME_COMPOSITION messages to su…

e2b8be8

…pport Unicode inputs on MBCS Windows. (ocornut#9099, ocornut#3653, ocornut#5961)

Uh oh!

Conversation

ulhc commented Nov 28, 2025

Uh oh!

ocornut commented Dec 1, 2025

Uh oh!

ulhc commented Dec 1, 2025

Uh oh!

ocornut commented Dec 1, 2025

Uh oh!

ulhc commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ocornut commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ulhc commented Dec 1, 2025

Uh oh!

ocornut commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ocornut commented Dec 1, 2025

Uh oh!

ulhc commented Dec 1, 2025

Uh oh!

ulhc commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ocornut commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ocornut commented Dec 1, 2025

Uh oh!

ulhc commented Dec 1, 2025

Uh oh!

ulhc commented Dec 1, 2025

Uh oh!

ocornut commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ocornut commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ulhc commented Dec 1, 2025

Uh oh!

ocornut commented Dec 1, 2025

Uh oh!

ocornut commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ocornut commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ocornut commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ulhc commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ulhc commented Dec 2, 2025

Uh oh!

ocornut commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ocornut commented Dec 3, 2025

Uh oh!

ulhc commented Dec 3, 2025

Uh oh!

ulhc commented Dec 3, 2025

Uh oh!

ulhc commented Dec 3, 2025

Uh oh!

ocornut commented Dec 3, 2025

Uh oh!

ocornut commented Dec 3, 2025

Uh oh!

ocornut commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ulhc commented Dec 3, 2025

ulhc commented Dec 1, 2025 •

edited

Loading

ocornut commented Dec 1, 2025 •

edited

Loading

ocornut commented Dec 1, 2025 •

edited

Loading

ulhc commented Dec 1, 2025 •

edited

Loading

ocornut commented Dec 1, 2025 •

edited

Loading

ocornut commented Dec 1, 2025 •

edited

Loading

ocornut commented Dec 1, 2025 •

edited

Loading

ocornut commented Dec 1, 2025 •

edited

Loading

ocornut commented Dec 1, 2025 •

edited

Loading

ocornut commented Dec 1, 2025 •

edited

Loading

ulhc commented Dec 2, 2025 •

edited

Loading

ocornut commented Dec 3, 2025 •

edited

Loading

ocornut commented Dec 3, 2025 •

edited

Loading