Imgui: ImGuiInputTextFlags_EnterReturnsTrue appears to only partially work

[ronniec95]

With a small example like this the first time I press enter the InputText returns true correctly.
But after that first time it continually returns true, even when I just type a character or mouseclick.
Is this expected behaviour, do I have to reset something to stop this?

        static const  ImGuiInputTextFlags flags = ImGuiInputTextFlags_EnterReturnsTrue;
    if (show) {
        ImGui::Begin("Test", &show, ImVec2(500, 500), 0.8f, ImGuiWindowFlags_NoResize);
        char fbuf[MAX_PATH] = { 0 };
        if (ImGui::InputText("Filename", fbuf, MAX_PATH, flags, &add_file_cb, fbuf) == true) {
            printf("Enter pressed");
        }
              ImGui::End()
      }

[ronniec95]

I found the issue. Could be a bug, but not sure
Reproduce by
Set breakpoint at printf(), wait 10 seconds, then continue.
Subsequently the InputText() box will return true/false intermittently for duration of window being open.
It seems to be related to this section of code on the delay timing but I'm not familiar enough with imgui to say for sure

bool ImGui::IsKeyPressed(int user_key_index, bool repeat) {
...
    if (repeat && t > g.IO.KeyRepeatDelay)
    {
        float delay = g.IO.KeyRepeatDelay, rate = g.IO.KeyRepeatRate;
        if ((fmodf(t - delay, rate) > rate*0.5f) != (fmodf(t - delay - g.IO.DeltaTime, rate) > rate*0.5f))
            return true;
    }

...
}

[ocornut]

Thanks, will look into it.
In your first message you suggest it it keeps returning true EVEN if Return is not pressed anymore?

[ronniec95]

Hi ocornut

Yes that's correct.

Failing test case:
Type input text : works fine, press RETURN, correctly triggers
Breakpoint at printf(), wait 10 seconds
Type more text, InputText returns true every character typed

Successful test case:
Type input text : works fine, press RETURN, correctly triggers
NO breakpoint
Type more text, InputText returns true on RETURN correctly

So from the code I think you are checking the time between keypresses here, but that could be an issue if the framerate drops below a certain threshold.

[ocornut]

@ronniec95 I can't repro the bug. Based on your description I think that your backend might have a bug when handling of key events.

Could you provide an actual standalone repro and test it within one of the examples/ framework?
You should also display the state of your enter key:
ImGui::Text("Enter %d", io.KeyDown[io.KeyMap[ImGuiKey_Enter]));

To make sure that it isn't stuck "Down".

[ocornut]

@ronniec95 Did you have a chance to check that and display the KeyDown[] and other keyboard states submitted by your app? Afaik there is no bug and I would like to close that unless proven wrong.

[ronniec95]

Hi I will take a look, sorry been busy with other projects. It's in the Direct3d11 sample application that I see the bug but I will put together a sample application.

[ocornut]

@ronniec95 Are you using the Navigation branch? (there was a bug in there which could have affected that, which I fixed yesterday).

If I add this code in the directx11 example I cannot find a problem:

            ImGui::Begin("Bug #1025");
            char fbuf[MAX_PATH] = { 0 };
            if (ImGui::InputText("Filename", fbuf, MAX_PATH, ImGuiInputTextFlags_EnterReturnsTrue, NULL, fbuf))
                printf("Enter pressed");
            ImGui::End();

[ocornut]

@ronniec95 ?

[ronniec95]

I tried with your fix and it looks ok now. So closing the issue

[Inc0ns1st3nt]

I m on windows 10, using v1.75, and am having this issue still.
I wonder if it has something to do with
GetAsyncKeyState(EnterKey) & 0b1
where without the 0b1, the key state for the argument key passed in, enter key, will continue to be registered as pressed

[Inc0ns1st3nt]

actually nvm it could be more of my own code, but this issue does not happen every time after enter press, but only after some cmd specifically (the console example)

[Inc0ns1st3nt]

It seems that if the breaks into the input method of the text bar in a debugger, it trigger this effect