Enum types in IDL and in code

[Stephan Bergmann]

On 07/21/2015 05:31 AM, Matthew J. Francis wrote:
> 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)

Old-style services that only list a bunch of properties, like 
css.style.ParagraphProperties, are mainly glorified documentation, 
telling a human that a UNO object documented to support that service is 
supposed to support an XProperty of the given name and type.

I am not aware that PyUNO nor the underlying UNO reflection/invocation 
facility actually make use of this information (but may well be wrong).

So when you say that "this is confusing for PyUNO," do you mean it is 
causing trouble somewhere in the innards of PyUNO (i.e., PyUNO or the 
underlying reflection/invocation is making use of the old-style 
properties-only service information after all), or do you mean it is 
causing trouble at the level of a Python program written assuming that 
reading some ParaAdjust value would provide some Enum value while in 
fact it provies an integer value (i.e., it is the author of the Python 
program who gets fooled by the inaccurate ParagraphProperties.idl file)?