You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
(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
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
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 tofalse
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:(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 aScrollKeyMod
variable to scroll events, or adding a newMouseWheelCtrl
,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 thatio.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
The text was updated successfully, but these errors were encountered: