Switching between control type using the same label hits assertion

[n0phx]

Version/Branch of Dear ImGui:

Version: 1.89.4
Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_opengl3.cpp + imgui_impl_glfw.cpp
Compiler: MSVC
Operating System: Windows 10

My Issue/Question:

When rendering either an int input or a combo control based on the value of a variable (and the controls use the same label, since only one of them will be rendered at any time based on the value), when switching back from the int input to combo, I hit an assert as seen in following screenshot.
Picking the value 2 in the combobox will switch to the int input control, and entering 0 into the int control will trigger the assert.

Screenshot:

Standalone, minimal, complete and verifiable example:

        static int itemIndex = 0;
        static int limit = 1;
        static const int itemCount = 3;
        static const char* items[] = {"0", "1", "2"};
        if (itemIndex < limit) {
            if (ImGui::BeginCombo("SharedControlName", items[itemIndex])) {
                for (int i = {}; i < itemCount; ++i) {
                    const bool isSelected = (itemIndex == i);
                    if (ImGui::Selectable(items[i], isSelected)) {
                        itemIndex = i;
                    }
                    if (isSelected) {
                        ImGui::SetItemDefaultFocus();
                    }
                }
                ImGui::EndCombo();
            }
        } else {
            ImGui::InputInt("SharedControlName", &itemIndex, 1, 100, ImGuiInputTextFlags_CharsNoBlank);
        }

Workaround #1 for problem:

Same snippet, only labels are unique:

        static int itemIndex = 0;
        static int limit = 1;
        static const int itemCount = 3;
        static const char* items[] = {"0", "1", "2"};
        if (itemIndex < limit) {
            if (ImGui::BeginCombo("NotSharedControlName1", items[itemIndex])) {
                for (int i = {}; i < itemCount; ++i) {
                    const bool isSelected = (itemIndex == i);
                    if (ImGui::Selectable(items[i], isSelected)) {
                        itemIndex = i;
                    }
                    if (isSelected) {
                        ImGui::SetItemDefaultFocus();
                    }
                }
                ImGui::EndCombo();
            }
        } else {
            ImGui::InputInt("NotSharedControlName2", &itemIndex, 1, 100, ImGuiInputTextFlags_CharsNoBlank);
        }

Hackaround #2 for problem:

Ugly tampering with imgui internals to simulate a mouse button down (in else branch of top-level if).

#include <imgui_internal.h>

...

        static int itemIndex = 0;
        static int limit = 1;
        static const int itemCount = 3;
        static const char* items[] = {"0", "1", "2"};
        if (itemIndex < limit) {
            if (ImGui::BeginCombo("SharedControlName", items[itemIndex])) {
                for (int i = {}; i < itemCount; ++i) {
                    const bool isSelected = (itemIndex == i);
                    if (ImGui::Selectable(items[i], isSelected)) {
                        itemIndex = i;
                    }
                    if (isSelected) {
                        ImGui::SetItemDefaultFocus();
                    }
                }
                ImGui::EndCombo();
            }
        } else {
            if (ImGui::InputInt("SharedControlName", &itemIndex, 1, 100, ImGuiInputTextFlags_CharsNoBlank)) {
                ImGuiContext* context = ImGui::GetCurrentContext();
                context->ActiveIdMouseButton = ImGuiButtonFlags_MouseButtonLeft;
            }
        }

[emoon]

Read https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-how-can-i-have-multiple-widgets-with-the-same-label

[ocornut]

As answered the simpler is you change the ID using some ## suffix, while keeping the same label.

Note thet doing this has one side effect which is that Keyboard/Gamepad Focus will be lost if it was on the swappes item. We are a missing a way to “recover” to nearest item which is something we should do eventually.

And generally I think we should still be looking at this as a bug and see if we can run without assert while causing harm to the stuff this is supposed to protect for. So i’ll look at this.

[n0phx]

Thanks for the replies, I was aware of the issues caused by two controls having the same ID, but I think this issue is different, because at no point in time will both controls be rendered at the same time, but depending on a variable, at each frame, only the code for one of them will be executed and one will be rendered, which makes me still lean towards treating this as a bug.

[GamingMinds-DanielC]

because at no point in time will both controls be rendered at the same time

But you have different controls with identical IDs in subsequent frames, making the state from the previous frame that is used for some things incompatible.

@ocornut: if you want to secure this the easy way, you could maybe push/pop different IDs based on the widget type onto the ID stack internally. Then only a switch between "different" widgets of the same type would go unnoticed, but they will have compatible internal state and therefore shouldn't pose a problem.

[ocornut]

While I consider this a little bit undefined-behavior, as-in, not all transition have been well thought out nor tested, I'm OK to fix cases as we go.
Pushed fix as part of 47a07d8
And Test ocornut/imgui_test_engine@fb750e5