ImGui::SliderInt without %.0f display format behaves diffrently...

[Demir-Fes]

Hello,
SliderInts diffrent each other, I wonder if it is my misundestanding or ... ?
static int i1=0;
static int i2=0;
ImGui::SliderInt("slider int 1", &i1, 0, 3);
ImGui::SliderInt("slider int 2", &i2, 0, 3, "test");
I use some text to display instead of display format.

[ocornut]

Hello,

Are you referring to the fact that the first line will display a drag box width that is 1/4 of the total width, and the second line a smooth drag box?

This is a side-effect of the fact that ParseFormatPrecision will fail to find a precision modified in the second format string and the default become %.3f because SliderInt() calls SliderFloat(). I can't think of a workaround right now, apart from making sure that your format string contains "%.0f".

I'll have to make a correct fix.

[Demir-Fes]

Thanks.

Are you referring to the fact that the first line will display a drag box width that is 1/4 of the total width, and the second line a smooth drag box?

Yes, I meant "drag box width".
I don't think it is a serious issue.

I tried to use sliderint like a combobox (display texts from char * items[])
ImGui::SliderInt("slider int", &i2, 0, 3, items[i2]);
yes it is related with including %.0f.

[ocornut]

I tried to use sliderint like a combobox (display texts from char * items[])

Nice idea :)
I would like to fix it. Right now the only reason it's not fixed already is that I am hesitant to duplicate the code of SliderFloat() into SliderInt() so I need to refactor it a little to share that code. This would also allow to fix another issue where text input for SliderInt() would break when using 23+bits because we do an int-float-int round trip there.

[ocornut]

Closing this old issue, @Demir-Fes, it has been solved in 1.61 by the refactor to support several types.

static int i1 = 0;
static int i2 = 0;
ImGui::SliderInt("slider int 1", &i1, 0, 3);
ImGui::SliderInt("slider int 2", &i2, 0, 3, "test");