Experimental macro features: How to determine object types?

Johnny_Rosenberg · October 14, 2019, 7:02pm

When using the experimental features in Basic I can declare thing in a more
specific way, for instance:

*Dim SomeSheet As com.sun.star.sheet.XSpreadsheet*
Without the experimental features enabled, I had to write this instead:
*Dim SomeSheet As Object*

Is there a way to find out for sure what type some object is supposed to be?
For instance, if I use Object instead and then look at it with XRay, in the
field just above the big field with all the
properties/methods/services/etc, it says *com.sun.star.sheet.XSpreadsheet*,
so that could be a clue, but it doesn't seem to always be usable.
For instance, when declaring a range, XRay says
*com.sun.star.table.XCellRange*, but declaring it like that won't work.
*com.sun.star.sheet.XSheetCellRange* will. How can I figure this out?

Mauricio_Baeza2 · October 14, 2019, 7:43pm

For use a type variable, this type should be "exposed" in the core, by example:

Dim s As String
Dim SomeSheet As com.sun.star.sheet.XSpreadsheet

But, if the type it's not present in core, you always get: "Unknown data", for example:

Dim sd As com.sun.start.util.SearchDescriptor

For this cases, we used Object.

Now, some objects, only can be instance from other objects, like SearchDescriptor

Dim sd As Object

doc = ThisComponent
sd = doc.createSearchDescriptor()

I hope clarify your question, and I hope have understand your question.

Best regards

sberg · October 15, 2019, 6:52am

When using the experimental features in Basic I can declare thing in a more
specific way, for instance:

*Dim SomeSheet As com.sun.star.sheet.XSpreadsheet*
Without the experimental features enabled, I had to write this instead:
*Dim SomeSheet As Object*

Is there a way to find out for sure what type some object is supposed to be?
For instance, if I use Object instead and then look at it with XRay, in the
field just above the big field with all the
properties/methods/services/etc, it says *com.sun.star.sheet.XSpreadsheet*,
so that could be a clue, but it doesn't seem to always be usable.
For instance, when declaring a range, XRay says
*com.sun.star.table.XCellRange*, but declaring it like that won't work.
*com.sun.star.sheet.XSheetCellRange* will. How can I figure this out?

(I have no idea what information that XRay tool prints, but:) A UNO object can implement multiple unrelated interfaces, and those interfaces in turn can each derive from (multiple) other interfaces. If you look at the UNO API documentation (<https://api.libreoffice.org/docs/idl/ref/index.html>, or the udkapi and offapi modules in the core git source repo), you see that css.sheet.XSheetCellRange is derived from css.table.XCellRange. The former adds one additional method, getSpreadsheet, so if you want to call that method you need to dim your var as the former, otherwise it suffices to dim it as the latter.

*com.sun.star.util.XSearchDescriptor*, but that only throws an error at
*SomeRange.createSearchDescriptor()*.

If you search for "createSearchDescriptor", there's css.util.XSearchable that has a method of that name, so you probably have an object at hand that implements that interface, and to hold that object you need a var that is dim'ed accordingly.

Johnny_Rosenberg · October 18, 2019, 6:16pm

Aaaaaaaa! Sorry, Stephan Bergmann! I accidentally replied to you, while my
intention was to reply to the list.
Here it is, this time to the list, and this time with further comments at
the end:

>:

> When using the experimental features in Basic I can declare thing in a
more
> specific way, for instance:
>
> *Dim SomeSheet As com.sun.star.sheet.XSpreadsheet*
> Without the experimental features enabled, I had to write this instead:
> *Dim SomeSheet As Object*
>
> Is there a way to find out for sure what type some object is supposed
to be?
> For instance, if I use Object instead and then look at it with XRay, in
the
> field just above the big field with all the
> properties/methods/services/etc, it says
*com.sun.star.sheet.XSpreadsheet*,
> so that could be a clue, but it doesn't seem to always be usable.
> For instance, when declaring a range, XRay says
> *com.sun.star.table.XCellRange*, but declaring it like that won't work.
> *com.sun.star.sheet.XSheetCellRange* will. How can I figure this out?

(I have no idea what information that XRay tool prints, but:) A UNO
object can implement multiple unrelated interfaces, and those interfaces
in turn can each derive from (multiple) other interfaces. If you look
at the UNO API documentation
(<https://api.libreoffice.org/docs/idl/ref/index.html>, or the udkapi
and offapi modules in the core git source repo), you see that
css.sheet.XSheetCellRange is derived from css.table.XCellRange. The
former adds one additional method, getSpreadsheet, so if you want to
call that method you need to dim your var as the former, otherwise it
suffices to dim it as the latter.

> *com.sun.star.util.XSearchDescriptor*, but that only throws an error at
> *SomeRange.createSearchDescriptor()*.

If you search for "createSearchDescriptor", there's css.util.XSearchable
that has a method of that name, so you probably have an object at hand
that implements that interface, and to hold that object you need a var
that is dim'ed accordingly.

This is what I don't really understand, I think.
From
https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1util_1_1XSearchable.html#a5e7b729c2d45dea6fa517b96e4e3feea
:
com::sun::util::XSearchDescriptor
<https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1util_1_1XSearchDescriptor.html>
createSearchDescriptor (
)
creates a SearchDescriptor
<https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1util_1_1SearchDescriptor.html>
which contains properties that specify a search in this container

It seems like Dim as com.sun.star.util.XSearchDescriptor should do it (and
both xray and mri describe them as such when Dim as Object, right after the
oRange.createSearchDescriptor() line).

I'm obviously approaching this the wrong way. Or I totally misunderstand
what ”and to hold that object you need a var that is dim'ed accordingly”
actually means.

I looked a little more into it and I finally got it to work. I'm not sure I
still understand this, but this works:

*Private Function ItemFound(sItem As string, _ oRange As
com.sun.star.sheet.XSheetCellRange) As Boolean Dim oDescriptor As
com.sun.star.util.XReplaceDescriptor
oDescriptor=oRange.createSearchDescriptor()*
*⁝*
*⁝*
*End Function*

So the answer to my question seems to be
”com.sun.star.util.XReplaceDescriptor”. Exactly why is a little blurry to
me at the moment.

Kind regards

Johnny Rosenberg

sberg · October 21, 2019, 10:53am

css.util.XReplaceDescriptor is derived from css.util.XSearchDescriptor. I assume that what dim'ing you need should depend on what you do with oDescriptor in the part you elided: If you only call XSearchDescriptor-methods on it, then dim as XSearchDescriptor should suffice. If you call any of the XReplaceDescriptor-only methods (getting/setting the ReplaceString), then you need to dim as XReplaceDescriptor.

Johnny_Rosenberg · October 21, 2019, 7:43pm

”oDescriptor=oRange.createSearchDescriptor()” line? I hadn't started to use
it yet…

Kind regards

Johnny Rosenberg

sberg · October 22, 2019, 7:00am

So what /is/ the exact error message?

Johnny_Rosenberg · October 22, 2019, 12:23pm

it in the thread, so maybe I just didn't.

The exact message is:
”Object not accessible.
Invalid use of an object.”

If I change the Dim statement from ”Dim oDescriptor As
com.sun.star.util.XSearchDescriptor” to ”Dim oDescriptor As
com.sun.star.util.XReplaceDescriptor”, the error message doesn't appear and
everything seems to work.

Example code for testing this:

*Sub Test Dim oRange As com.sun.star.sheet.XSheetCellRange
oRange=ThisComponent.getSheets().getByIndex(0).getCellRangeByPosition(0,0,10,10)
Dim oDescriptor As com.sun.star.util.XSearchDescriptor
oDescriptor=oRange.createSearchDescriptor() ' Gives an error message.End
Sub*

*Sub Test Dim oRange As com.sun.star.sheet.XSheetCellRange
oRange=ThisComponent.getSheets().getByIndex(0).getCellRangeByPosition(0,0,10,10)
Dim oDescriptor As com.sun.star.util.XReplaceDescriptor
oDescriptor=oRange.createSearchDescriptor() ' Works fine.End Sub*

I just think it's a little funny: I want to create a search descriptor, but
”declaring” it as such doesn't work, I need to ”declare” it as a replace
descriptor. It's a little hard to take those things in.

Kind regards

Johnny Rosenberg

Johnny_Rosenberg · October 22, 2019, 12:40pm

Two steps:
1. Tools ⇨ Options… ⇨ ▼ LibreOffice ⇨ Advanced ⇨ ☒ Enable experimental
features (may be unstable)
2. Tools ⇨ Options… ⇨ ▼ LibreOffice ⇨ Basic IDE ⇨ ☒ Use extended types

Kind regards

Johnny Rosenberg

sberg · October 23, 2019, 1:27pm

<https://gerrit.libreoffice.org/#/c/81386/> "In checkUnoObjectType, check for derived-from types too" should fix it

sberg · October 23, 2019, 3:01pm

Turns out I assumed wrongly there about how LO Basic behaves. In the true spirit of dynamically typed languages, you can apparently call any method actually supported by the object, regardless of the "dim as" type of the variable that holds the object. (Only when assigning the object to the variable are types checked to match---and were checked in an inferior way, see my other mail announcing a fix.)