Repository: ocornut/imgui

Issue #2062: Stuck Key Input Issue and Misdetected keys
Created: 2018-09-04T23:39:35Z
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.

Duplicate issue #2976: [win32] Standard shortcuts stop working in input widgets
Created: 2020-01-11T09:52:24Z
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.

Closing comment (2020-01-11T16:59:02Z): 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.