Discrepancy between SfxItemSet::SET and com::sun::star::frame::status::ItemState::SET
erack at redhat.com
Mon Oct 16 12:18:05 UTC 2017
On Saturday, 2017-10-07 19:07:13 +0900, Takeshi Abe wrote:
> Found that SfxItemSet::SET's value is different from css::frame::status::ItemState::SET,
> I have uploaded a patch  for consistency of the UNO API.
> It seems unlikely that this issue is relevant to other existing bugs, since
> each entry of SfxItemState is used only as a nominal value in the code base.
> Anyway my understanding is limited, experienced eyes may see subtle consequences
> from this issue/change.
>  https://gerrit.libreoffice.org/#/c/43190/
Indeed the old SET value of 0x0030 being DONTCARE|DEFAULT doesn't make
much sense. A SET value may not only indicate a non-default pool item
value, but also an explicitly set default value of the pool item, hence
maybe the DEFAULT bit value, but DONTCARE doesn't fit there, it looks
like that or'ed mask never was intended and no place uses it.
I checked places with SfxItemState::SET that do not use == or != or
assignments or return, leaving comparisons with < or <= or >, and these
seem not to rely on the bit value.
Also places that use SfxItemState::DEFAULT or SfxItemState::DONTCARE
don't use a bit mask to extract a value, so we seem to be good.
I'll push the patch.
Last, even the comment at SfxItemState says "These values have to match
the values in the css::frame::status::ItemState IDL" ...
Maybe the SfxItemState values should be initialized using the IDL
constants as a follow-up.
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the LibreOffice