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