How to handle key events properly. about imgui HOT 7 OPEN

Who is supposed to set io.WantCaptureKeyboard?

Active text input fields, or via ImGui::SetNextFrameWantCaptureKeyboard(true). See Demo > Inputs & Focus > WantCapture override.

from imgui.

Yes, that does it and the right place to put it seems to be

          if (ImGui::IsWindowFocused(ImGuiFocusedFlags_ChildWindows))
          {
            ImGui::SetNextFrameWantCaptureKeyboard(true);  // << GOOD LOCATION
            if (ImGui::IsKeyChordPressed(ImGuiKey_Space | ImGuiMod_Ctrl))
            {
               // DO NOT PUT IT HERE!
               //
               // handle keypress

I looked at InputText and it seems to use a different system (g.ActiveId), but I think it is beyond the scope of the issue to understand the difference.

Instead I wanted to ask: imagine a child of the above widget is already handling key events (via the same method or like InputText): how to I filter this case to only capture residual key events? In a more traditional widget system, when an event is accepted it stops being propagated. Is it possible here?

from imgui.

Don't know if I should open a new issue or continue here.

This is about selecting widgets using TAB.
I see it is already enable for InputText and this can be controlled via PushTabStop.

But for TabItems, is it possible to cycle through the selected tab using TAB?

from imgui.

Instead I wanted to ask: imagine a child of the above widget is already handling key events (via the same method or like InputText): how to I filter this case to only capture residual key events? In a more traditional widget system, when an event is accepted it stops being propagated. Is it possible here?

The current mechanism which I am pushing for but isn't fully documented is a mix of setting and testing for key ownership and/or registering shortcut routes (the later register key ownership when the mods matches).

If you call Shortcut(ImGuiKey_Space | ImGuiMod_Ctrl) in both parent and child location, you'll find that only the deep most one gets the shortcut. It's a rather complex multi-faceted problem that doesn't have a single answer, but if you want to detail your use case I may be able to suggest a direction.

Unfortunately this mechanism doesn't necessarily set io.WantCaptureKeyboard for the "background" application to use.
Technically your key handler could also check if a key is owned (if (ImGui::GetKeyOwner(ImGuiKey_XXXX) == ImGuiKeyOwner_None) and use that as a secondary filter to not pass keys to background application. However this would only work for code that is setting key ownership correctly. Some randomly placed IsKeyPressed(ImGuiKey_XXX) unless SetKeyOwner() is also called, which standard widgets do, and which e.g. Shortcut() will do indirectly do.

This is about selecting widgets using TAB.
I see it is already enable for InputText and this can be controlled via PushTabStop.
But for TabItems, is it possible to cycle through the selected tab using TAB?

I don't understand what you are saying here. It looks like a different topic, is it? If it a different topic please open a new issue and provide more details.

from imgui.

Thank you for the explanation. I was not aware of Shortcut, nor KeyOwner.

I see them in imgui_internal.h. I will look to see if I understand them, but I fear that until they land in the Demo I will have a hard time.

For the time being, I have rearranged a bit the hierarchy to remove the ambiguity, but I will keep an eye on further developments.

from imgui.

Sorry I meant to add there is a public branch with a bunch of demos for those functions as well. I can’t merge the demos before i move those public to api realm, but i think most are pretty stable now. My main bother is that outside of just using Shortcut(), the system can be a bit confusing

from imgui.

The demos are here:
master...features/demo_input_owner_and_routing

from imgui.