-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Simple way to scroll to a widget and give it keyboard focus? #2021
Comments
Hello, No need for a repro, it's a known issue (see e.g. #343) and I am aware of the inconsistency with the "Here" concept :( A while ago I started a work-in-progress branch to ditch I think a workaround you may use to get Note that 1.60+ has -Omar |
I have successfully worked around this challenge in my code already, by just having some global variable I set temporarily after the impulse is detected, and clear on the next frame. I wanted to file this ticket as sort of a "feature request" to make this simpler in some way. Maybe My use case is changing the control that has focus, depending on some outside input. In my case, it is selecting one of the several widgets in my 3D scene that will cause the corresponding field in the 2D UI to gain focus. The window probably will already be open when I want this focus change to happen. |
The future/intended new API |
Should I close this ticket then, since it is sort of a dupe/there's planned features for this already? |
Closing! Thanks for the reminder that this needs to be sorted out :) |
v1.53 (can't easily update right now, in case this is easier in a newer version)
Is there a simple way to scroll to a widget and give it keyboard focus? Right now it seems like I need to jump through some hoops to get it to work right.
The only way I've gotten it to work right:
SetScrollHere
SetKeyboardFocusHere
If I call
SetKeyboardFocusHere
without callingSetScrollHere
first, then it does nothing, unless I already have the window scrolled to the right place.If I call
SetScrollHere
then immediately callSetKeyboardFocusHere
, either immediately before or immediately after the widget call, then the wrong thing gets focused.In my experiments, it also seems like
SetScrollHere
andSetKeyboardFocusHere
have different concepts of "here", and the order they need to be invoked (list at the top) makes it pretty hard to use.Please let me know if you want a minimal repro to accompany this, or if it is already clear enough.
The text was updated successfully, but these errors were encountered: