SliderInt, CTRL Click doesn't update var?

[dacobi]

Dear ImGui 1.89.3 WIP (18927)
SDL2
G++ 11.3.0
Ubuntu 22.10

I have a problem with my code where CTRL Clicking a SliderInt doesn't update the int variable.

I have a function to set 3 SliderInt's RGB values which is called when a color is selected in my palette editor.
mR, mG,mB are public members of TPalette.

void TPalette::setEditColor(){
	mR = (mEditColor.x * 255.0f) / 16;
	mG = (mEditColor.y * 255.0f) / 16;
	mB = (mEditColor.z * 255.0f) / 16;
}

And then in my render function I set the Sliders to display a string value.

	const char *mRval = mMapColorVals[mR].c_str();
	const char *mGval = mMapColorVals[mG].c_str();
	const char *mBval = mMapColorVals[mB].c_str();

	ImGui::SliderInt("Red", &mR, 0, 15, mRval);
	ImGui::SliderInt("Green", &mG, 0, 15, mGval);
	ImGui::SliderInt("Blue", &mB, 0, 15, mBval);

Everyting works except that when I CTRL click a Slider and enter a value my mR, mG,mB, variables are not changed and the Slider returns to the previous value.
Dragging the Sliders works as expected.
The mR,mG,mB variables are not changed anywhere else in the render function.

Do I need to do something else?

Please let me know if there is any other information I need to supply.

[ocornut]

There’s probably a bug in code you omitted.
Try to construct an actually minimal complete and verifiable repro and while doing that you will likely find your issue.

[dacobi]

I just can figure out what should be wrong.

I tried changing one of the Sliders to use a mTest int var that is only ever set to an initial value of 0 in the constructor, but the behavior is the same. Dragging works fine, but when entering a value in text field mode it returns to the previous value when I hit Enter.

[dacobi]

The problem happens when using "const char* format" in the SliderInt. Without this everything works fine.
(Edit) I've changed my format strings to include "%d" and now it works.

[ocornut]

I gave you an answer. Please read it again and read issues guidelines and you will get closer to solving your problem. We cannot magically guess what those values and variable and missing code are.

[dacobi]

It does work now, I just don't understand why. Is it correct behavior that it's necessary for the format string to need "%d" for the text field mode to work?

That's the only thing I've changed and now everything works as expected.

[ocornut]

Is it correct behavior that it's necessary for the format string to need "%d" for the text field mode to work?
That's the only thing I've changed and now everything works as expected.

Ok. Now you are giving useful data to craft a repro. Thanks.

So you suggest this doesn’t work:

ImGui::SliderInt(“test”, &myint, 0, 100, “foobar”); ?

I am not in front of the computer to confirm right now, but if this doesn’t work I would consider it a bug which we should fix.

[dacobi]

ImGui::SliderInt(“test”, &myint, 0, 100, “foobar”);

This will not work with text field mode on my system, but when adding "%d" it works fine.

My format strings now look like this

std::vector<std::string> mMapColorVals = {"%d/0","%d/17","%d/34","%d/51","%d/68","%d/85","%d/102","%d/119","%d/136","%d/153","%d/170","%d/187","%d/204","%d/221","%d/238","%d/255"};

[ocornut]

I have pushed a fix for this: 6cdedf5
Thanks for reporting!

(The reason I am asking for minimal repro if that if you straight posted "ImGui::SliderInt(“test”, &myint, 0, 100, “foobar”); doesn't work" in your first message I would immediately understand what's going on. Vs posting more complex code referring to data the reader has no way of knowing about.)

[dacobi]

On Tue, 9 May 2023, 12:07 omar, ***@***.***> wrote: I have pushed a fix for this: 6cdedf5 <6cdedf5> Thanks for reporting!

Thank you for the fix. The problem with posting a repro was that I didn't understand what was wrong, but I assumed I was doing something wrong rather than it being a bug. So it took a while to figure it out. (The reason I am asking for minimal repro if that if you straight posted

…

"ImGui::SliderInt(“test”, &myint, 0, 100, “foobar”); doesn't work" in your first message I would immediately understand what's going on. Vs posting more complex code referring to data the reader has no way of knowing about.) — Reply to this email directly, view it on GitHub <#6405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVWEIAH7FB7PPGW4I7KZA3XFIJMVANCNFSM6AAAAAAXXEKGOE> . You are receiving this because you authored the thread.Message ID: ***@***.***>