[Solved] Test Objects for identity

[Lupp]

Suppose I have two files, created by storeToURL from the same SpreadsheetDocument without any changes in-between.

Later I opened both these copies from user code and chose TWICE one of these two components RANDOMLY from the StarDesktop both times assigning the first sheet to an object variable, the first time to vari1, the second time to vari2.

How can I distinguish between vari1, vari2 being two ways of access to the SAME thing and vari1, vari2 pointing to DIFFERENT objects only having every property beyond the origin in common.

Precautionary remark:
EqualUNOObjects ALWAYS returns FALSE for sheets, ranges, cells and the like, even for the same object created in the same way twice.
I could not yet find a property pointing "upwards" from a sheet (like .Parent or .Component or .Model or ...).
This looks strange to me. However, even for TextDocument where everything seems to point upwards and often infinitely loops back to self from seemingly subordinate properties, nothing points to the model. This MIGHT be intended. For security/saftey? For what reasons?

[RoryOF]

This may be a manifestation of the underlying code (C++?), dealing with variables "by reference" or "by value". If one could access their address in RAM, identical addresses might indicate "by reference". There may be other methods of resolving this problem.

[JeJe]

You could set a userdefinedattribute for the sheet to the URL when you assign the variable perhaps?

[Lupp]

Yes and thanks for your interest.
Well, I wouldn't even need to assign anything to the object, if I keep it as one element of an array or a structure where the other element is the model from which it was taken or something identifying it.

The question is more about understanding the "Why? - Or is it different?". A specific application would be a way to pass a cell / cellrange to a Sub/Function, not needing to pass anything else even if the routine needs access to different sheets or to any property of the model for its working.

Insofar you may see my starting point in the question:
"How can I get as an object the SpreadsheetDocument a sheet passed as a Var parameter to a routine belongs to?"

As soon as I have a reliable test for identity, I can at least find a workaround concerning the second (and more practical) question by comparing any given sheet whith any equally named and equally indexed sheet of any .SpreadsheetDocument accessible via the StarDesktop.

[Villeroy]

The Ho Chi Minh trail from a cell (InitialTarget) down to the forms collection and up to the document:

Code: Select all   Expand viewCollapse view

Sub Snippet(Optional oInitialTarget As Object)
  Dim oSpreadsheet As Variant
  Dim oDrawPage As Variant
  Dim oForms As Variant
  Dim oParent As Variant
  Dim sURL As String

  oSpreadsheet = oInitialTarget.getSpreadsheet()
  oDrawPage = oSpreadsheet.getDrawPage()
  oForms = oDrawPage.getForms()
 
  oParent = oForms.getParent()
  sURL = oParent.getURL()
End Sub

[Lupp]

@Villeroy:
You are a great guerilla fighter, obviously! Did you find that path using your warrior's guide, or was there a stroke of ingeniousness? Second alternative surely!
"So einfach - und man kommt nicht drauf!" (I much less use forms than you do.)
Anyway, a conscious decision to not allow the access to the model based on a subordinate object should be ruled out by that. Oddrr?

[Lupp]

The problem is solved concerning the secondary, more practical question.
Concerning the original topic in general I may have to wait for results in pursuit of this bug report to the TDF: https://bugs.documentfoundation.org/sho ... ?id=125421.

[Villeroy]

I stumbled over it when looping through a hierarchy of forms, subforms and form controls down and then up again. The surprising thing is that you go down from a sheet's draw page into the forms hierarchy and calling getParent several times, you finally land on the document itself.