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.

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).
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.

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
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.
Most helpful comment
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.