Apache OpenOffice (AOO) Bugzilla – Issue 67774
Odd handling of DataArray pseudoProprty
Last modified: 2017-05-20 11:11:44 UTC
I wrote a macro which included the use of DataArray access to convert columns containing formulas to their literal equivalent (as in copy/paste value). I first tried oRange.DataArray = oRange.DataArray which is supposed to be semantically equivalent to oRange.setDataArray(oRange.GetDataArray() but it isn't -- the first leaves the formulas unchanged and the second doesn't. I simplified it down to the following code which repeatedly shows the issue: rB2 = ThisComponent.Sheets(0).getCellByPosition(1, 1) rB2a = rB2 rB2b = ThisComponent.Sheets(0).getCellByPosition(1, 1) rB2.Formula = "=Row()" : rB2.DataArray = rB2.DataArray : Print rB2.Formula rB2.Formula = "=Row()" : rB2a.DataArray = rB2.DataArray : Print rB2.Formula rB2.Formula = "=Row()" : rB2b.DataArray = rB2.DataArray : Print rB2.Formula rB2.Formula = "=Row()" : t=rB2.DataArray : rB2.DataArray=t : Print rB2.Formula rB2.Formula = "=Row()" : rB2.setDataArray(rB2.getDataArray): Print rB2.Formula 1 & 2 return the ROW() formula, 3-4 return the value. It's the fact that the second fails and the third works. Clearly it fails when the variants are pointing to the same object (e.g. rB2 and RB2A) as opposed to two separate but identical objects (R2 and R2B)
This is an in-progress update. No immediate action required. I've had a further look at this one. In fact it doesn't seem to be anything to do with the Calc engine. It is a combination of two errors, both in the API / Basic RTS, and have therefore moved it to Andreas B to monitor. I have included a small Calc Test Harness to how the bug manifests itself more clearly. (1) The RTS evaluates d.DataArray = s.DataArray differently depending on whether EqualUnoObjects(d,s) is true or false. The timings indicate that the RTL is going down completely different code paths for these two cases, and only when using the Pseudo-property DataArray. (2) The trend in run times is disturbing and indicates that you've got leakage / fragmentation in your storage management. This shouln't be happening at this scale? Are you using the STL default allocator? I will by putting up my own OOo test bed within a week or so, so when I get time I'll buzz the code through and give you a proposed set of exact line fixes.
Created attachment 38655 [details] Q n D Calc ODS to demonstrate feature
set the target and confirm
STARTED
The subroutine Sub assign(s,d) d.DataArray = s.DataArray End Sub Generates the assembly STMNT 19,0 (For-Level: 0) assign: STMNT 21,0 (For-Level: 0) PARAM 2; Object ELEM DataArray; Variant PARAM 1; Object ELEM DataArray; Variant PUT STMNT 22,0 (For-Level: 0) LEAVE As fas as I can see, the problem is in sbxvalue.cxx. The routine SbxValue::Put( const SbxValues& rVal ) contains the test to abort the assignment if the objects are identical: case SbxOBJECT: if( !p->IsFixed() || p->aData.eType == SbxOBJECT ) { // ist schon drin if( p->aData.eType == SbxOBJECT && p->aData.pObj == rVal.pObj ) break; This is clearly flawed in some circumstances: break if "ist schon drin" is the wrong thing to do in the case: d.DataArray = s.DataArray where d and s point to the same object.
change target from 2.x to 3.x according to http://wiki.services.openoffice.org/wiki/Target_3x
Reset assigne to the default "issues@openoffice.apache.org".