Testing UNO API service properties
sbergman at redhat.com
Tue Mar 27 08:29:00 UTC 2018
On 27/03/18 05:38, Jens Carl wrote:
> On 03/26/2018 12:51 AM, Stephan Bergmann wrote:
>> Can you give an example in the source code of a UNO service
>> implementation passing properties as a sequence of PropertyValue?
> For FunctionDescription the code is here
So ScFunctionListObj is a C++ implementation for UNO objects that, among
others, implement the UNOIDL css.sheet.XFunctionDescription interface.
That interface in turn has a method getById that returns a
In a rather unfortunate and confusing way,
offapi/com/sun/star/sheet/XFunctionDescriptions.idl mentions the
css.sheet.FunctionDescription old-style (see below) service description
as a source of documentation for that sequence<css.beans.PropertyValue>.
Documenting such a sequence<css.beans.PropertyValue> with an old-style
service description (that lists only properties, no interfaces nor
super-services) is a misuse of the UNOIDL concepts. But a misuse that
goes unpunished, because it's all merely documentation.
So as a user you can guess from the documentation that the
sequence<css.beans.PropertyValue> returned by getById will have five
elements, "Id" of UNO type LONG, "Category" of UNO type LONG, etc. And
such a sequence is a "pure" value detached from the object from which it
was obtained via getById, so changing its elements wouldn't have any
effect on the original object. That's probably the reason why the
properties of that misused css.sheet.FunctionDescription are marked as
readonly. Even if it is technically nonsense, it expresses the moral
equivalent of there being no way to change the original object's values
that are obtained via getById.
("New-style" services are syntactically declared in UNOIDL to be of one
specific interface type,
service Foo: XFoo;
and there's a guarantee that you can obtain that service at the global
service manager, and it will support that specific---typically
multiple-inheritance---interface. On the other hand, "old-style"
services are just glorious documentation. They lump together multiple
interfaces and properties and other super-services, but do not really
say anything about how instances of such services are obtainable. Some
describe global services similar to new-style ones, others describe
objects that are obtained through other factory mechanisms. And yet
others, just listing a bunch of properties, document just a set of
"properties", however those will be implemented.)
More information about the LibreOffice