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

SetKeyboardFocusHere() issue with changing widgets #432

Closed
jristic opened this issue Dec 11, 2015 · 3 comments
Closed

SetKeyboardFocusHere() issue with changing widgets #432

jristic opened this issue Dec 11, 2015 · 3 comments
Labels
bug nav keyboard/gamepad navigation

Comments

@jristic
Copy link

jristic commented Dec 11, 2015

I'm messing around with the sample node editor code you posted (https://gist.github.com/ocornut/7e9b3ec566a333d725d4) and while implementing rename, I noticed an odd issue. With the following code, the SliderFloat will end up getting focus after hitting enter on the InputText.

if (RenameNodeID == node->ID) {
    ImGui::SetKeyboardFocusHere();
    if (ImGui::InputText("##name", node->Name, 32, 
        ImGuiInputTextFlags_AutoSelectAll | ImGuiInputTextFlags_EnterReturnsTrue)) 
    {
        RenameNodeID = -1;
    }
}
else {
    ImGui::Text("%s", node->Name);
}
ImGui::SliderFloat("##value", &node->Value, 0.0f, 1.0f, "Alpha %.2f");

However the following will not show the same problem.

ImGui::InputText("##name", node->Name, 32, ImGuiInputTextFlags_AutoSelectAll | ImGuiInputTextFlags_EnterReturnsTrue);
ImGui::SliderFloat("##value", &node->Value, 0.0f, 1.0f, "Alpha %.2f");

Thoughts?

@jristic
Copy link
Author

jristic commented Dec 11, 2015

And of course I've just realized this is because I should only be calling SetKeyboardFocusHere() once. Is there an easy way to do this without adding a do-once flag?

@ocornut
Copy link
Owner

ocornut commented Dec 11, 2015

Hello,

An extra condition flag may be useful using an _Appearing condition but otherwise not much. In the Console demo code I test if no widgets are active before calling SetKeyboardFocusHere().

However, either way the behavior you are reporting is a bug. The reason is that SetKeyboardFocusHere() currently defer the focus setting to the next frame because it may be called with a negative parameter. I have a todo entry to handle that better, either by handling >= 0 offsets immediately either by locking on the id to focus so that when you press Enter and stop displaying your widget it won't focus another one. Currently focusing is expecting stable widget order so changing the widget breaks it.

I'll look this this issue but I don't know when. Fix shoulnd't be too hard.

@ocornut ocornut added the bug label Dec 11, 2015
@ocornut ocornut changed the title Enter from InputText is passing keyboard focus to next element SetKeyboardFocusHere() issue with changing widgets Dec 11, 2015
rokups added a commit to rokups/imgui that referenced this issue Apr 24, 2020
rokups added a commit to rokups/imgui that referenced this issue Jul 15, 2020
rokups added a commit to rokups/imgui that referenced this issue Jul 15, 2020
rokups added a commit to rokups/imgui that referenced this issue Jul 15, 2020
@ocornut ocornut added the nav keyboard/gamepad navigation label Sep 6, 2021
ocornut added a commit that referenced this issue Oct 6, 2021
…for clipped items. (#343, #4079, #2352, #432)

+ Removed references to counter used by previous implementation of SetKeyboardFocus functions (the TabStop ones will be removed after)
@ocornut
Copy link
Owner

ocornut commented Oct 6, 2021

Better late than never :) This is now fixed by the current rework of the tabbing system.
31d033c should fix it.

@ocornut ocornut closed this as completed Oct 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug nav keyboard/gamepad navigation
Projects
None yet
Development

No branches or pull requests

2 participants