How to stop text from being received by an inputtext when it's not being shown?

[xaxxon]

I've written a text console overlay that gets hidden/shown when the tilde key is pressed. The code for making the window is wrapped in an if block and the value of that boolean is changed when the user presses the tilde key (SDL_KEYDOWN on SDLK_BACKQUOTE).

However, either when it's being shown or being hidden (I'm not sure, but I press tilde twice and I only get one in the inputtext), the SDL_TEXTINPUT event goes through and the ` is added to the inputtext.

In my code for drawing the window, I have ImGui::SetKeyboardFocusHere(); called right before the inputtext so it doesn't lose focus when enter is called (I have return true on enter flag set) so I can reset the text to blank and have the user continue typing after enter is pressed.

How do I stop the ` from getting through to the inputtext?

Thank you so much! ImGui has saved me so much time and allowed me to add features I would have never even bothered with because they would have taken so much time. Especially love the up/down history and tab completion.

[xaxxon]

Or any insight into a better fundamental approach to this would be good.
I've worked around it by simply testing for the string "`" before passing the keyboard event into imgui and that works fine for now, but it's a blight on my otherwise perfect codebase :)

[ocornut]

Well first you'd want to figure out if you are catching the text input when being shown or being hidden (you can do so by mapping show and hide on to two different keys).
It looks like it would be a logic ordering bug on your side.
If you are doing

• poll input
• flip switch on backquote press
• call imgui code if switch is set

I'm not sure how that would fail.

[xaxxon]

I always have to call the imgui event handler in case there are other
windows up and doing things, though.. and my impression is that it thinks
the keyboard focused element is the inputtext that I don't want the data
going to.

On Sun, Nov 29, 2015 at 1:49 AM, omar notifications@github.com wrote:

Well first you'd want to figure out if you are catching the text input
when being shown or being hidden (you can do so by mapping show and hide on
to two different keys).
It looks like it would be a logic ordering bug on your side.
If you are doing

• poll input
• flip switch on backquote press
• call imgui code if switch is set

I'm not sure how that would fail.

—
Reply to this email directly or view it on GitHub
#418 (comment).

[ocornut]

I don't understand. Could you provide some repro code based on the samples?

[ocornut]

OK I have created a repro (key value for GLFW here).

        static bool opened = false;
        if (ImGui::IsKeyPressed(GLFW_KEY_1))
            opened ^= 1;
        if (opened)
        {
            ImGui::Begin("Test");
            ImGui::SetKeyboardFocusHere();
            static char buf[256] = "hello";
            ImGui::InputText("input", buf, 256);
            ImGui::End();
        }

I am not sure it constitute a bug per-se. Text inputs receive the text inputs that are available and if your program looks anything like mine above there's no input capturing. The InputText() receive your input at the time is appears. Perhaps when you read the tilde key you can do a ImGui::GetIO().InputCharacters[0] = 0; to clear the text buffer or perhaps clear your keys buffer as well.

The subtle underlying bug that makes this NOT happen the first time is because the effect of SetKeyboardFocusHere() is deferred by one frame(as discussed in #432 and I aim to fix that).

By the way instead of caling SetKeyboardFocusHere() every frame I recommend that you do something like:

            if (!ImGui::IsAnyItemActive())
                ImGui::SetKeyboardFocusHere();

or

            if (ImGui::IsRootWindowOrAnyChildFocused() && !ImGui::IsAnyItemActive())
                ImGui::SetKeyboardFocusHere();

Depending on what you want.

[ocornut]

I'll close this as there are variety of ways around (and yours is ok now). but let me know if there is something you're not sure about. It's a bit annoying that so many API aren't passing keypresses and text input in the same message (holding both values) it would allow easier filtering of that sort. Having effectively two streams of data (key presses and character) when you can't fully process them right away create this situation. I'm not sure how to do better at this point but it'll be an interesting edge case to consider if we refactor the input system.