Thank you @Othereum for this PR.

I have a question: what is the reason for testing #if HAS_WIN32_IME to process the WM_IME_CHAR message?
Could we just handle WM_IM_CHAR in every builds? Does it needs to be filtered by !UNICODE as well?

Well, maybe HAS_WIN32_IME doesn't need to be checked. However, UNICODE must be checked.

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

As you can see here, if the project uses unicode character set, wParam has a unicode encoded value. Therefore, you just need to add the input immediately without any further action.

Well, maybe HAS_WIN32_IME doesn't need to be checked. However, UNICODE must be checked.

Then I suggest you then remove that check and move the other function was it was previously to minimize the patch?

About unicode checking, I have also been used to test the UNICODE define but I wonder if we should simply just called IsWindowUnicode() to decide whether the process the message.

Oh, you're right. Then why don't we merge it into master branch instead of docking branch? Should I make a new PR?

I retested it when I got home and it didn't work properly when I enabled UTF-8 support in the system locale settings. So I fixed it using the ImmGetCompositionStringW() function.
Therefore, I think that the HAS_WIN32_IME check should be retained, and this PR should be merged into the docking branch.

I'm still waiting for your review, @ocornut :D

Hello,
I'll wait until after 1.80 to test and review this thoroughly. Thank you for your patience!

Well, maybe HAS_WIN32_IME doesn't need to be checked. However, UNICODE must be checked.

Then I suggest you then remove that check and move the other function was it was previously to minimize the patch?

About unicode checking, I have also been used to test the UNICODE define but I wonder if we should simply just called IsWindowUnicode() to decide whether the process the message.

fyi:
The result of IsWindowUnicode can change during the lifetime of a window.
Initially it's determined by how the class is registered (RegisterClassExA or RegisterClassExW),
but it can be changed by calling SetWindowLongPtrW(hwnd, GWLP_WNDPROC,..) to turn it into unicode, or SetWindowLongPtrA(hwnd, GWLP_WNDPROC,..) to turn it back to ANSI.

@learn-more

The result of IsWindowUnicode can change during the lifetime of a window.

Is that something that realistically happen?

@Othereum I wanted to look at this today but I am confused.
On the example_win32_dx11 project if I change back "Character" to "Use Multi-Byte Character Set" everything seems to work without this patch.
Can you clarify what are the steps to reproduce the issue prior to applying your patch?

I verified that my project compiles with:

#ifdef UNICODE
#error
#endif
#ifdef _UNICODE
#error
#endif

Aka neither are defined.

@learn-more

The result of IsWindowUnicode can change during the lifetime of a window.

Is that something that realistically happen?

I am in the middle of moving, so don't have access to my notes, but if I recall correctly this is something that can happen when a window is subclassed, or flags of the window are altered.

By the way we are discussing and resurrecting this over #9099 and hopefully will submit a solution soon.

As posted in the other issue, it is correct that this PR cannot handle input of multiple consecutive characters. If I e.g. input 日本語 into the IME and then press ENTER only the first character ends up being submitted. The fix would be:

    case WM_IME_COMPOSITION:
    {
        //IMGUI_DEBUG_LOG("WM_IME_COMPOSITION wParam %08X, lParam %08X\n", wParam, lParam);
        if (lParam & GCS_RESULTSTR)
        {
            if (HIMC himc = ::ImmGetContext(hwnd))
            {
                LONG buffer_size = ::ImmGetCompositionStringW(himc, GCS_RESULTSTR, NULL, 0);
                ImVector<WCHAR> buffer;
                buffer.resize((int)buffer_size / sizeof(WCHAR));
                ::ImmGetCompositionStringW(himc, GCS_RESULTSTR, buffer.Data, buffer_size);
                ::ImmReleaseContext(hwnd, himc);
                for (WCHAR c : buffer)
                    io.AddInputCharacterUTF16(c);
            }
        }
        return 0;
    }
    case WM_IME_CHAR:
        return 1; // IME is processed above, so return 1 so that the WM_CHAR message is not generated.

But I am aiming at a solution closer to #9099 so we don't require the user to link with imm32.lib.

This should now be solved by 962cc23 + 87b1933 + d27dce5. Thank you!