The subject should tell everything.
Using Basic all the ways I could imagine were tried.
The service seems to not be listed among the AvailableServiceNames for a spreadsheet document.
SheetCellRange can’t create an instance at all.
A createSheetSortDescriptor2 (or any similarly named) method doesn’t exist.
The Basic function CreateInstance() returns Null used with the mentioned service name.
Hello! This service is not used directly. The createSortDescriptor and Sort methods use the sequence of PropertyValue. The names of properties of sequence correspond to the names of properties of the mentioned service.
Thanks.
Buit I can’t seriously believe that a simple aide-memoire concerening the oder of properties was established as a service.
Perhaps the developers had some plans for this service (not yet implemented).
1 Like
css::sheet::SheetSortDescriptor2 bundles only properties and has no interfaces and only includes service css::table::TableSortDescriptor2 that again only bundles properties …
Services not exposing an interface can not be instantiated.
I don’t recall a specific reason why these “property bundle services” were done that way, maybe it was the only way to specify those loose properties in the IDL. (and probably still is).
Why not implement the “thing” as a unoStruct then?
Just to avoid the “stabbing in the dark” concernnig the unspecified order, functionality, and defaults of what’s returned by sheetCellRange.createSortDescriptor() (a sequence of com.sun.star.beans.PropertyValue).
Once again: The .sort(applicableSequence) method itself identifies the used property values by name, not by index. .
The comparable case of filtering is implemented with the help of SheetFilterDescriptor and XSheetFilterDescriptor iin a completely different (mentally incompatible) way.
Properties are not really suited to be squeezed into structs. While initially it could be similar, a published struct can not be changed, not even by adding new members, without breaking the API. A service’s properties can be amended by adding optional properties.
But there is code in the world relying on the indices of the sequence created by SheetCellRange.createSortDescriptor(), and this code will break if the unspecified order is changed.
Which doesn’t happen if optional properties are appended to the end.
… of course.
Can you understand that i’m not exatly glad with the assumption devolpment won’t break their unspoken obligation?
There is the PropertyBag service not relying on indices.