-
-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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
Mouse-wheel scroll behaviour over child windows #2604
Comments
This is an interesting idea, I admit I hadn't thought of doing it this way (locking the target scrolling window until moving the mouse again). I'll give it a try when possible. I think OS X behaves the same way as we currently do. Also see #1245 |
(Apologies, I have posted a message stating this was fixed but was thinking of a totally different issue. Deleted the wrong message and re-opened this.) |
…l the mouse is moved again or until a short delay expires (2 seconds). This allow uninterrupted scroll even if child windows are passing under the mouse cursor. (#2604)
Hello @Tom-Evers Very happy with this improvement! |
Version/Branch of Dear ImGui:
Version: 1.71
Branch: docking
Back-end/Renderer/Compiler/OS
Back-ends: imgui_impl_win32.cpp + imgui_impl_dx11.cpp
Operating System: Windows 10
My Issue/Question:
When scrolling a tall list that contains another scrollable field, that subfield 'captures' the mousewheel scroll action.
This should not be default behaviour: when the mouse does not move, the mousewheel should keep affecting the field that the scroll action originated in.
Screenshots/Video
Standalone, minimal, complete and verifiable example:
Build and run the docking branch.
The text was updated successfully, but these errors were encountered: