Since 19ead810d (#9511), ColorButton() and ColorPicker4() cancel out the
dimming of an enclosing BeginDisabled() by restoring the alpha it saved:
if (g.DisabledStackSize > 0)
g.Style.Alpha = g.DisabledAlphaBackup;
DisabledStackSize > 0 means "inside some BeginDisabled() call", not "items
are disabled". BeginDisabled(false) increments DisabledStackSize but does
not write DisabledAlphaBackup, which is only written when a BeginDisabled()
call actually starts disabling. Inside BeginDisabled(false) the swatch
therefore picks up whatever value DisabledAlphaBackup holds from elsewhere:
- 0.0f, its initial value, when no BeginDisabled(true) has run in the
context yet: the swatch is fully transparent and only its border shows.
- The style alpha of the last BeginDisabled(true) anywhere in the context
(another window, an earlier frame): the swatch looks correct when that
was 1.0f, and is drawn with an unrelated alpha when it ran under a pushed
ImGuiStyleVar_Alpha.
So a swatch's appearance depends on whether, and under which alpha, some
unrelated widget was disabled earlier. Typical trigger is the
BeginDisabled(condition) idiom with the condition false, e.g.:
ImGui::BeginDisabled(is_read_only); // false
ImGui::ColorEdit3("##color", col, ImGuiColorEditFlags_NoInputs);
ImGui::EndDisabled();
In a fresh context this draws an empty swatch frame; it starts showing the
color only after any other window draws a disabled item.
Fix: cancel out the dimming only while the Disabled item flag is set, i.e.
while an enclosing BeginDisabled(true) is in effect. DisabledAlphaBackup
then always holds the alpha that call saved, and inside BeginDisabled(false)
the swatch draws with the current style alpha, as any other widget does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Note that the 32-256 ranges may seem misleading because ImVector<> handle its growth policy but it is also the size we request to underlying user impl hence the clamps.
- With MixedValue+LiveEdit: a single edit that ends up with same output reports as edited.
- Standardize path sin TempInputscalar(), InputScalar(), InputTextEx().
- Refer to changes in imgui_test_suite, in particular "widgets_datatype_1", "widgets_status_liveedit_off",
Omar: couldn't detect any output difference in test suite with large u64/s64 ranges drag/sliders.
I believe this is entirely theoretical and it's principal value is to shut Linter warnings
The main fix is the change from GetColorU32() to ColorConvertFloat4ToU32() in calling code.
The change from GetColorU32() to manual multiply in RenderColorRectWithAlphaCheckerboard() is merely for consistency with other ::Render calls.