The ParagraphProperties service contains, among other things, the
properties:
com::sun::star::style::ParagraphAdjust ParaAdjust
com::sun::star::style::GraphicLocation ParaBackGraphicLocation
where ParagraphAdjust and GraphicLocation are both enum types.
However, while reading ParaBackGraphicLocation actually gives an enum
value, ParaAdjust appears to be implemented and handled as a sal_Int16
(UNO short). This is confusing for PyUNO and presumably anything else
which relies on inspecting the type of the property.
(Blindly assigning an enum value to this property results in an integer
with the right value being assigned, but the PyUNO Enum doesn't
currently internally contain or know anything about the integer value,
so for instance there's no way to compare the two for equality in Python
code)
Should we:
a) Incompatibly change the most holy IDL
b) Change all the internal code which reads/writes it as a bare integer,
equally risking incompatibility with some unknown external user who
was relying on it being "really an integer"
c) Suck our teeth and deal with it as a wart at the PyUNO level (though
are there in fact any / many other instances of this? It would be nasty
to add that affordance if this were the only one)
d) Run away screaming
Or, is there some reason why this situation is considered legitimate?
Regards
Matthew Francis
Context
- Enum types in IDL and in code · Matthew J. Francis
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.