Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't CTRL-scroll an unfocused platform window: Wheel events on unfocused windows have no way to access "true" key mod state #5840

Open
pmttavara opened this issue Oct 31, 2022 · 0 comments

Comments

@pmttavara
Copy link

pmttavara commented Oct 31, 2022

My Issue/Question:

When a window does not have keyboard focus, and receives a mouse wheel event from the OS, that event may have key modifiers associated with it. (See, for example, documentation on WM_MOUSEWHEEL on Windows: https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel)

However, I do not see a way for a naive/opaque user of Dear Imgui (who hasn't edited the backend) to obtain the key modifier state in that case. For example, when handling CTRL-scroll, I can't check ImGui::GetIO().KeyCtrl, because all key modifiers are overridden to false at all times while the window is unfocused.

This issue is the result of important fixes made to resolve #2622 and #4377, among other issues (#2062, #3532, #3961, etc.).

As an app developer, solving this issue is easy for me, because I can edit imgui_impl_win32.cpp's window proc handler as such:

    case WM_MOUSEWHEEL:
        io.KeyCtrl = IsVkDown(VK_LCONTROL) || IsVkDown(VK_RCONTROL);
        io.KeyShift = IsVkDown(VK_LSHIFT) || IsVkDown(VK_RSHIFT);
        io.KeyAlt = IsVkDown(VK_LALT) || IsVkDown(VK_RALT);
        io.AddMouseWheelEvent(0.0f, (float)GET_WHEEL_DELTA_WPARAM(wParam) / (float)WHEEL_DELTA);
        return 0;

(This solution is bugged in that it causes the modifier key bools to "stick" until the next mouse wheel event; that's fine for our app, but a general solution would make the modifier boolean "flash" for the single frame that the mouse wheel delta is reported.)

However, I think it might be helpful for Dear Imgui to expose a clear way to users to get the key modifier state without writing an app-specific modification like mine.

Unfortunately, I don't know whether the Dear Imgui team wants the behaviour in the solution I gave, because it breaks the implicit constraint currently present that says: "unfocused windows shall never have any key modifiers set". It may make other users' windows flash or unexpectedly change if they're receiving CONTROL or ALT key presses when the window is not focused. I don't know how many users currently rely on that behaviour!

I've been suggested that Dear Imgui could introduce a new set of key modifiers, e.g., io.KeyCtrlUnfocused, io.KeyShiftUnfocused, io.KeyAltUnfocused, io.KeySuperUnfocused that will reflect the "true" state of the key modifiers specifically for this kind of use case. There are two other, scroll-specific solutions that I can think of: either attaching a ScrollKeyMod variable to scroll events, or adding a new MouseWheelCtrl, MouseWheelAlt, etc. wheel delta per key modifier. (That last solution would let the user handle multiple different types of scroll happening within one frame, but that sounds like overkill, and again these solutions are specific to scroll events and don't generalize the way that io.KeyCtrlUnfocused would.)

Version/Branch of Dear ImGui:

Version: 18818
Branch: I have observed this to be the case on master & docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_win32.cpp + imgui_impl_dx9.cpp
Compiler: Clang 14.0.6
Operating System: Windows 10 x64 21H2

@ocornut ocornut added the inputs label Oct 31, 2022
@ocornut ocornut changed the title Can't CTRL-scroll an unfocused window: Wheel events on unfocused windows have no way to access "true" key mod state Can't CTRL-scroll an unfocused platform window: Wheel events on unfocused windows have no way to access "true" key mod state Nov 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants