Enum types in IDL and in code

[Matthew J. Francis]

On 07/08/2015 16:00, Miklos Vajna wrote:
> Hi,
>
> On Fri, Aug 07, 2015 at 01:07:52PM +0800, "Matthew J. Francis" <mjay.francis at gmail.com> wrote:
>> Mainly the latter confusion. The problem the user I was discussing this
>> with had was that when trying to develop using such an interface you
>> have no idea what the value you receive from it is unless you can find
>> it in the IDL, and when you do so it suggests that it should have been
>> an actual enum to begin with.
>
> If the IDL documentation and the actual code differs in such enum vs int
> types, I think the best would be to adjust the documentation to match
> the code, and not the other way around.

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.

An equivalent constant group could be added, although that would be not
ideal in a different way - the original enum definition couldn't be
removed, as it may still be used for instance by existing Python code
to blindly assign values to the property.

Any advance then on the idea of:
- Making the declared type short
- Adding a constant group for it
- Deprecating the enum

I note that for this particular case, css::report::XReportControlFormat
declares a ParaAdjust attribute which is actually a short - the
documentation would need changing there to reference the new constant
group, but not the definition.

Regards
Matthew Francis