Can't select only 1 input when inputs are slightly close to each other about imgui

[GamingMinds-DanielC]

Classic id conflict, see here for details:
https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-about-the-id-stack-system

It has nothing to do with proximity on the screen. You basically have submitted multiple items with the same id, reacting as one. One way you can solve it is by using ImGui::PushID( (int)row ); and ImGui::PopID(); at the start and end of your loop body.

[ocornut]

FYI if you use PushID(row) you don't need to decorate label names, a simple ##DistanceDrag works.

Please browse the Tables section of the Demo as it exhibit many use cases.

[ocornut]

Closing as answered, thank you Daniel!
Indeed the provided link should give you all answers.
I will amend the FAQ entry with a GIF to highlight the common issue.

[ocornut]

I added code (c383795e) to generate this gif:

And added it to the FAQ entry, along with corresponding UI code.

[AshKetshup]

Thanks for your time, I've been so lost lately with this problem

[AshKetshup]

I'm sorry I have to reopen the issue, I'm not sure if I understood this. I tried using the PushID and PopID calls to manage this it.
I've read somewhere in a closed issue that naming a label with a pre "##" would hide the label during rendering, even tho it is true on a different row of my table ends up pasting the label without the first character. While it starts messing with the other input fields. Not sure if it is a pointer problem or something related to me using a vector<pair<float, float>> levels to this particular case. I'll be posting also a gif representing this problem.

Here's my updated code:

{
	if (ImGui::Begin("Tesselation Shader Properties")) {
		if (tS.levels.size() == 0)
			tS.levels.push_back({ 0.f, 0.f });

		sortVPair(tS.levels);
		
		static ImGuiTableFlags flags = ImGuiTableFlags_ScrollY | ImGuiTableFlags_RowBg | ImGuiTableFlags_BordersOuter | ImGuiTableFlags_BordersV | ImGuiTableFlags_Reorderable | ImGuiTableFlags_Hideable;

		if (ImGui::BeginTable("table_scrolly", 2, flags, ImVec2(-FLT_MIN, 5 * ImGui::GetTextLineHeightWithSpacing()))) {
			for (size_t row = 0; row < tS.levels.size(); row++) {
				ImGui::TableNextRow();
				{
					ImGui::TableNextColumn();

					ImGui::PushID(row);
					ImGui::DragFloat("##DistanceDrag" + (row), &( tS.levels[row].first ), 1.f, 0.f, 0.f, "Distance > %.1f");
					ImGui::PopID();
				}

				{
					ImGui::TableNextColumn();

					ImGui::PushID(row);
					ImGui::DragFloat("##LevelDrag" + (row), &( tS.levels[row].second ), 1.f, 0.f, 0.f, "Level : %.1f");
					ImGui::PopID();
				}
			}

			ImGui::EndTable();

		}

		if (ImGui::Button("+"))
			tS.levels.push_back({ 0.f, 0.f });

		ImGui::SameLine();

		ImGui::BeginDisabled(tS.levels.size() <= 1);
		if (ImGui::Button("-"))
			tS.levels.pop_back();
		ImGui::EndDisabled();


		ImGui::End();
	}
}

[GamingMinds-DanielC]

Your problem is here:
"##DistanceDrag" + (row)

That is not how you construct strings in C++. That's pointer arithmetic. You basically take the string, which is a char*, then offset the pointer itself by the current value of row. So your labels for rows 0, 1 and 2 are "##DistanceDrag", "#DistanceDrag" and "DistanceDrag" respectively, which fits with the observed behavior.

If you want to build your labels with values pasted in, that's called string formatting. One of many ways: take a look at sprintf_s and use it to format a string into a local char array of sufficient size.

[AshKetshup]

@GamingMinds-DanielC That does solve the label issue, for sure. I was wondering if it actually had something to do to pointer arithmetic. Although the behaviour itself of the change of values affecting the other fields keeps going and since the smoking gun of pointer arithmetic was already found, i then don't know what might be the problem in the first place. Nice catch tho, thanks.

Btw, I ended up using std::format since I'm working with C++20.

TLDR: Labels are now actually invisible but the fields interfering with each other persists.

[GamingMinds-DanielC]

TLDR: Labels are now actually invisible but the fields interfering with each other persists.

I'm pretty sure this is your culprit: sortVPair(tS.levels);

You should avoid changing underlying values (if you swap them due to sorting, that counts) while you are actively editing them. My advice would be to sort only after an edit, ImGui::IsItemDeactivatedAfterEdit() can help with that.

[AshKetshup]

Thanks, that seems to solve the case! You were right. Since I have your attention do you know how in my case I could make the element widgets stretch themselves to the full width of the cell?

[GamingMinds-DanielC]

Since I have your attention do you know how in my case I could make the element widgets stretch themselves to the full width of the cell?

Never tried if that works in table cells, but you can try ImGui::SetNextItemWidth(-FLT_MIN). Slightly negative as an offset to the available size. If that doesn't work, you need to calculate or know the size yourself and can use that as a positive value.

[AshKetshup]

Thanks to you both. Its all up and running. Thanks for your help!