[win32] Standard shortcuts stop working in input widgets

[crackedmind]

Version/Branch of Dear ImGui:

Version: 1.75 WIP (17401)
Branch: master and docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_sdl.cpp and imgui_impl_glfw.cpp
Operating System: Windows 10 1909

My Issue/Question:
Standard ctrl based hotkeys for input widgets stop working after using some windows/keysuper system shortcuts like win+space (change input language) and win+v (clipboard history, appeared in Windows 10 1809). It stops working until window reactivation.

Problem is here:

imgui/examples/imgui_impl_glfw.cpp

Line 124 in f03c00b

io.KeySuper = io.KeysDown[GLFW_KEY_LEFT_SUPER] || io.KeysDown[GLFW_KEY_RIGHT_SUPER];

imgui/examples/imgui_impl_sdl.cpp

Line 118 in f03c00b

io.KeySuper = ((SDL_GetModState() & KMOD_GUI) != 0);

And when we pressed: win-space, then ctrl-z. we got is_shortcut_key == false, because io.KeySuper ==1 and io.KeyCtrl also equals to 1.

imgui/imgui_widgets.cpp

Line 3671 in f03c00b

const bool is_shortcut_key = (is_osx ? (io.KeySuper && !io.KeyCtrl) : (io.KeyCtrl && !io.KeySuper)) && !io.KeyAlt && !io.KeyShift; // OS X style: Shortcuts using Cmd/Super instead of Ctrl

I don't know why KeySuper state not clears after KEYUP event. As workaround i use #ifndef _WIN32 guard

In pure win32 backend io.KeySuper always sets to false.

imgui/examples/imgui_impl_win32.cpp

Line 223 in f03c00b

io.KeySuper = false;

Standalone, minimal, complete and verifiable example:
Just open Demo window in default sdl/glfw examples and go to Multi-line text widget example.

[ocornut]

Thank you for the report. This is the first time I use Win+V I didn't even know this feature existed.

So it looks like there are multiple issues at end:

(1) Investigate why SDL and GLFW don't correctly report when the Super/GUI key is released. I tested with GLFW and confirmed that KeySuper was stuck after releasing it after a Win+V.

In this screenshot the Win+V ui is open, and the Windows key has been released already and it's still reported as pressed: (note that text appearing in the OS UI on the top-right is just my clipboard history!).

This is essentially similar to #2062 in essence.

(2) Investigate if we could expose the Super key in imgui_impl_win32.cpp, when I looked it wasn't obvious to me how to read that key.

---

My intuition is the following:

• The "Windows key" is not really properly usable for user applications under Win32, and because of this neither SDL nor GLFW have worked out nice workarounds to catch when it has been released.
• Maybe we easily prove that both SDL and GLFW have a bug and possibly aim to report and fix it there.
• If that's the case, since this is a key that's difficult to even access/use under Windos, my suggested answer for both 1 and 2 is simply to not forward the key in the SDL and GLFW backup when running on Windows (so simply #ifdef that section out of both back-ends).

In fact that later option we should apply right now, since that's the immediate best fix we have, while we investigate SDL/GLFW further.

[rokups]

Reason for this happening is that WM_KEYUP is not sent for Super keys upon release in some cases. This explains why both GLFW and SDL have same issue - it is win32 problem. Both libraries would require a workaround for this quirk. This conclusion is based on testing win32_dx11 example.

A workaround:

    io.KeysDown[VK_LWIN] &= (::GetKeyState(VK_LWIN) & 0x8000) != 0;
    io.KeysDown[VK_RWIN] &= (::GetKeyState(VK_RWIN) & 0x8000) != 0;
    io.KeySuper = io.KeysDown[VK_LWIN] || io.KeysDown[VK_RWIN];

This clears keys in stuck state manually. Bonus: it also implements Super modifier.

Problem is actually deeper than this. Turns out any key will get stuck in a pressed key state because win32 does not send WM_KEYUP to unfocused window. It is unclear what the right solution is here.

---

Reported bugs:

• https://bugzilla.libsdl.org/show_bug.cgi?id=4939
• Keys can get stuck in pressed state glfw/glfw#1622

[rokups]

This will be fixed in next GLFW release.

[ocornut]

Closing this as a non-dear imgui issue, reported to GLFW and SDL and fixed in GLFW. Thanks Stanislav and Rokups.