Enum types in IDL and in code

[Matthew J. Francis]

On 07/08/2015 17:32, Miklos Vajna wrote:
> Hi,
>
> On Fri, Aug 07, 2015 at 04:52:36PM +0800, "Matthew J. Francis" <mjay.francis at gmail.com> wrote:
>> How specifically should that be changed, though. In this case, merely
>> changing the declared type to short would leave it such that its value
>> is defined by the set of integer values of an enum, which is still
>> annoying in terms of manipulation using PyUNO and peculiar in terms of
>> the IDL.
>
> If the documentation says that this is a short, exact possible values
> are defined here and there, I don't see that worse than the current
> situation. :-)

It's not worse, but also not by itself a solution for an important part
of the problem, which is that you currently can't compare a value from
this property with anything in PyUNO - only assign blindly to the
property (unless you go to the trouble of defining your own constants
from reading the IDL)

If there's a constant group, since a recent change you can

   import something.Group

then

   if obj.SomeProperty == Group.VALUE: ...


If there isn't, I'll have to also do something similar to make Enums
aware of their value set (which may be a good idea anyway), and make
them int-comparable as mentioned previously (which is ickier, Python
avoids doing this in its more recently added native Enum class - you
have to explicitly use an IntEnum for that).

[...]

> In case all other ParaAdjust implementations (I'm sure at least editeng
> has one) also deal with a sal_Int16 in fact, then just changing
> '[property] com::sun::star::style::ParagraphAdjust ParaAdjust;' to
> '[property] short ParaAdjust;' in the IDL file (and using a comment to
> still refer to the enumeration informally) would make sense, I think.
> Even if the in-build check complains that this is nominally an
> incompatible change.

Unfortunately it looks like this may not be the case.
chart2/source/model/main/Title.cxx / 
offapi/com/sun/star/chart2/Title.idl look suspicious for one. If 
different implementations of the ParagraphProperties service disagree 
about the real type, then I don't see a way to make everything 
consistent compatibly.


Regards
Matthew Francis