Enum types in IDL and in code
Matthew J. Francis
mjay.francis at gmail.com
Mon Jul 20 20:31:32 PDT 2015
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
More information about the LibreOffice
mailing list