Testing UNO API service properties

[Stephan Bergmann]

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 
> https://opengrok.libreoffice.org/xref/core/sc/source/ui/unoobj/appluno.cxx#578 

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 
sequence<css.beans.PropertyValue>.

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.)