Download it now!
Bug 125421 - The Basic function EqualUnoObjects wrongly returns False for two variables having assigned the same object by different ways of access.
Summary: The Basic function EqualUnoObjects wrongly returns False for two variables ha...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected)
3.3.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2019-05-21 13:52 UTC by Wolfgang Jäger
Modified: 2020-07-21 09:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

The example announced in the report (10.18 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-05-21 13:52 UTC, Wolfgang Jäger
EqualUnoObjects - working example with controls (9.88 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-05-22 17:18 UTC, Oliver Brinzing

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Jäger 2019-05-21 13:52:47 UTC
Created attachment 151563 [details]
The example announced in the report

Having a sheet with a shape anchored to a cell we can get the cell using the sheet's method getCellByPosition. We can get the same cell object via the shape's .Anchor property.
Now we can apply the function EqualUnoObjects() to the two representations of the same object.
Expected result: True
Actual result:   False
Thorough inspection of both representations in the IDE doesn't show any differences. Same (respective) result for
EqualUnoObjects(ThisComponent.Sheets.GetByIndex(0), _

If the function not was implemented for the comparison of ANY kind of objects, but only for UnoStruct e.g. this should be explicitly stated somewhere (since I assume that a respective change of the name not is acceptable). The result in cases of undue application concerning the type of objects should be an error then instead of the nwrong (at least gravely misleading) False.

Testing was done with OOo V3.2 and with LibO V

The behaviour obviously is common heritage of LibO and AOO.

See attached demo.
Comment 2 Julien Nabet 2019-05-21 19:59:06 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

Since in this part:
   3171     if( x1 == x2 )
   3172     {
   3173         refVar->PutBool( true );
   3174     }

x1 isn't considered as == to x2, refVar stays at false.

Now I don't know how to fix this or if we should fix this.
Indeed, I suppose it may have impacts on existing macros.
Comment 3 Wolfgang Jäger 2019-05-21 22:55:22 UTC
I should subjoin that even the expression 

EqualUnoObjects(ThisComponent.Sheets.GetByIndex(0), ThisComponent.Sheets.GetByIndex(0))

will return False.
Comment 4 Oliver Brinzing 2019-05-22 17:18:59 UTC
Created attachment 151602 [details]
EqualUnoObjects - working example with controls

adding a working example, searching a control on drawpage
Comment 5 Wolfgang Jäger 2019-06-21 10:51:39 UTC
You may also have a glance at a related post in a forum where sometimes actual discussion occurs:
Comment 6 Mike Kaganski 2020-07-21 09:20:39 UTC
We actually do create a new object each time a range object is requested (see e.g. ScTableSheetsObj::GetObjectByIndex_Impl[1], which implements functionality of XIndexAccess::getByIndex). So at least in case of range objects (which have their range read-only, thus for all uses should be considered "same" when refer to same range), we need some special casing to check if they are objects of the same type (e.g., one could be "sheet", and the other "all cells, but not sheet", and these are different objects), and then refer to the same range.