https://bugs.documentfoundation.org/show_bug.cgi?id=172054
--- Comment #5 from Michael Weghorn <[email protected]> --- Thanks a lot for the analysis and fix! (In reply to Michael Massee from comment #0) > 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. >From an API perspective, that was/is so far an implementation detail that was never documented anywhere, so technically macros or extensions should never have relied on it (or it should have been documented earlier). Of course, it makes sense to bring it back, however, if they do. Would you mind also submitting a follow-up change to actually document that behavior in `offapi/com/sun/star/cui/ColorPicker.idl`, so it's clear that this is actually part of the "contract"/now published API and won't break again in the future without being noticed? -- You are receiving this mail because: You are the assignee for the bug.
