Stuck Key Input Issue and Misdetected keys

[DrJedikiah]

Latest version of ImGui and every renderer in win32

Lately I made a custom widget which is a hotkey container for assigning keys to jobs. My issue is if you change the active window while you holding a key, key becomes stuck in pressed state and only pressing again that key solves that problem. To demonstrate it, just open the ImGui xxxx example doesn't matter the renderer just win32, and go to the inputs section and keyboard mouse states. After that just try to alt tab (easy demo) or activate another window while you holding a key. You will see that key is flashing like pressing rapidly in "key pressed:" section. That causes to not detecting the proper keystroke.

[ocornut]

You are right. We don't receive the WM_KEYUP events after we lost focus.
Perhaps we could decide on a policy such as clearing the key down state when receiving a WM_KILLFOCUS message?

Happy to hear feedback of how people handle this sorts of thing their own engine?

In dear imgui world this becomes a little more involved in the Viewport branch as there are multiple Win32 windows at play. I'll look at it eventually (suggestion/fixes that are compatible with the Viewport branch are welcome).

[DrJedikiah]

Thanks for the help, I've tried to clear key down state but it changes to true (the stuck key state) everytime because windows thinks the key is still physically down. So I made something like this and now works perfectly but it's not the most efficient way of doing this I think.

[DrJedikiah]

Update:

case WM_SETFOCUS:
        for ( int i = 0; i < 512; i++ ) {
            keybd_event( (BYTE)i, MapVirtualKeyA( (BYTE)i, 0 ), 0x0002, 0 );
        }
        return 0;

I've refined the code but forgot to publish. Adding this to WndProcHandler will solve the issue.

Additional way:

case WM_SETFOCUS:
        std::fill_n( io.KeysDown, 512, 0 );
        return 0;

if you include you can use it like this very simple and short.

[mrdooz]

Thanks for the easy fix! I was running into the same issue when I was hitting a breakpoint inside my code that responded to InputText returning true, so the debugger stole input and the WM_KEYUP got lost.

[ocornut]

#3961 suggested using:

    case WM_KILLFOCUS:
        memset(io.KeysDown, 0, sizeof(io.KeysDown));
        return 0;

I however mentioned that the problem is that none of those strategy works for multi-viewports, but I'll look for a solution that is multi-viewports compatible.

[ocornut]

I pushed the WM_KILLFOCUS suggested fix now : 1491d2c

As it happens, in docking + multi-viewports enabled it does make held key flick off for one frame, but this issue has also been present in the GLFW backend and no-one noticed that before, so my conclusion is that it's a much less problematic issue than the one we are fixing now. We can improve on the multi-viewports code later.

[JoshuaWebb]

Could/should the same fix be implemented in the backend for io.MouseDown? It isn't nearly as common to lose focus while a mouse button is down as it is for the keyboard, so I'm happy to just handle it in my own code, but I ran into it today so thought it was worth asking.