https://bugs.documentfoundation.org/show_bug.cgi?id=172054
Bug ID: 172054
Summary: cui.ColorPicker / ui.dialogs.ColorPicker: dialog opens
with default color, initial color from
setPropertyValues("Color", ...) ignored (regression in
26.2)
Product: LibreOffice
Version: 25.2.2.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: [email protected]
Reporter: [email protected]
Description:
Description:
The UNO color picker service `com.sun.star.cui.ColorPicker` (alias
`com.sun.star.ui.dialogs.ColorPicker`) accepts an initial color via
`XPropertyAccess.setPropertyValues("Color", ...)` and stores it in
`m_aColor`, but `ColorPicker::execute()` never propagates that value
to the `ColorDialog` instance. As a result, the dialog always opens
with the default color (black), regardless of what the caller set.
This breaks any non-trivial caller (extensions, macros) that needs
to edit an existing color.
Steps to Reproduce:
>From an extension or macro:
Set up:
XComponentContext ctx = ...;
Object inst = ctx.getServiceManager()
.createInstanceWithArgumentsAndContext(
"com.sun.star.cui.ColorPicker",
new Object[] { parentXWindow }, ctx);
XPropertyAccess pa = UnoRuntime.queryInterface(XPropertyAccess.class,
inst);
PropertyValue pv = new PropertyValue();
pv.Name = "Color";
pv.Value = 0xFF0000; // red
pa.setPropertyValues(new PropertyValue[] { pv });
XExecutableDialog dlg =
UnoRuntime.queryInterface(XExecutableDialog.class, inst);
dlg.execute();
Actual Results:
Color dialog opens with the default color (black).
Expected Results:
Color dialog opens with the red color preselected.
Reproducible: Always
User Profile Reset: No
Additional Info:
Regression analysis
===================
The pre-2025-06 implementation in cui/source/dialogs/colorpicker.cxx
did seed the dialog by passing mnColor to the ColorPickerDialog
constructor:
std::unique_ptr<ColorPickerDialog> xDlg(new ColorPickerDialog(
Application::GetFrameWeld(mxParent), mnColor, mnMode));
The service was dropped in commit 5ba0ccb2964da46d32ade0c87baf2d407cb52a8a
("[API CHANGE] Drop ColorPicker, AsynchronousColorPicker", 2025-06-16)
and reintroduced in commit 9d6ade1f3b8e4ee59ae7bbe7fda440152af60221
("[API CHANGE] Reintroduce com.sun.star.ui.dialogs.ColorPicker",
The pre-2025-06 implementation in cui/source/dialogs/colorpicker.cxx
did seed the dialog by passing mnColor to the ColorPickerDialog
constructor:
std::unique_ptr<ColorPickerDialog> xDlg(new ColorPickerDialog(
Application::GetFrameWeld(mxParent), mnColor, mnMode));
The service was dropped in commit 5ba0ccb2964da46d32ade0c87baf2d407cb52a8a
("[API CHANGE] Drop ColorPicker, AsynchronousColorPicker", 2025-06-16)
and reintroduced in commit 9d6ade1f3b8e4ee59ae7bbe7fda440152af60221
("[API CHANGE] Reintroduce com.sun.star.ui.dialogs.ColorPicker",
2025-11-18) without the seeding logic. The subsequent refactor in
commits 86a04e193376 / cbfae1c3be2d1c ("tdf#169505 Use ColorDialog in
ColorPicker") preserved the regression ? `ColorDialog::SetColor()` is
never called before `ColorDialog::Execute()`.
Current code in vcl/source/components/ColorPicker.cxx:
sal_Int16 SAL_CALL ColorPicker::execute()
{
ColorDialog aColorDialog(Application::GetFrameWeld(m_xParent));
const int nRet = aColorDialog.Execute(); // ? no SetColor call
if (nRet == RET_OK)
m_aColor = aColorDialog.GetColor();
return nRet;
}
Proposed fix
============
One-liner ? call SetColor before Execute:
sal_Int16 SAL_CALL ColorPicker::execute()
{
ColorDialog aColorDialog(Application::GetFrameWeld(m_xParent));
+ aColorDialog.SetColor(m_aColor);
const int nRet = aColorDialog.Execute();
if (nRet == RET_OK)
m_aColor = aColorDialog.GetColor();
return nRet;
}
Patch attached.
--
You are receiving this mail because:
You are the assignee for the bug.
