Bug 146873 - Macro: bug in CoreReflection after Split() + arrayed( Array() )
Summary: Macro: bug in CoreReflection after Split() + arrayed( Array() )
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected) alpha0+
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2022-01-20 12:39 UTC by Kamil Landa
Modified: 2022-02-24 06:32 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:

OK in Watch, but error in CoreReflection (35.76 KB, image/png)
2022-01-20 12:39 UTC, Kamil Landa

Note You need to log in before you can comment on or make changes to this bug.
Description Kamil Landa 2022-01-20 12:39:49 UTC
Created attachment 177671 [details]
OK in Watch, but error in CoreReflection

If I transform the Array() created by Split() to the Array( Array() ), then it shows Error for CoreReflection. 
But if the Array() is created by definition =Array(...), then it is OK. 
Run this macro:

Sub bugInSplitArrayArray
	dim p(), i%, s$, oReflection as object, o as object
	p=Split(s, "-") 'BUG, it shows error
	'p=Array("a", "b", "c") 'but for this Array it is OK
	for i=lbound(p) to ubound(p)
		p(i)=Array( p(i) )
	next i
	o=oReflection.getType(p) 'Error
	msgbox o.TypeClass 'if OK it shows 20
End Sub

Version: (x64) / LibreOffice Community
Build ID: 151c56ed547490a99d912524c0e56b5d6d4a1939
CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win
Locale: cs-CZ (cs_CZ); UI: en-US
Calc: CL

but for example OK in
Version: (x64)
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: cs-CZ (cs_CZ); UI: cs-CZ
Calc: CL
Comment 1 Andreas Heinisch 2022-01-20 13:43:52 UTC
We changed split in https://gerrit.libreoffice.org/c/core/+/123122, thid could affect the core reflection. I have to test it though.
Comment 2 Andreas Heinisch 2022-02-23 20:30:28 UTC
@Mike: Should we allow in [1] also non fixed variant arrays? Since the new split function [2] resets the fixed flag and changes the type to variant? Imho the GetByte function should allow all kind of retrievals.

[1] https://opengrok.libreoffice.org/xref/core/basic/source/sbx/sbxstr.cxx?r=5bd55c22#87
[2] https://gerrit.libreoffice.org/c/core/+/123122/6/basic/source/runtime/methods1.cxx#1632
Comment 3 Mike Kaganski 2022-02-24 06:32:43 UTC
(In reply to Andreas Heinisch from comment #2)

At https://opengrok.libreoffice.org/xref/core/basic/source/classes/sbunoobj.cxx?r=a2eaf99e#1010, the Type for 'p' is obtained, which is typelib_TypeClass_SEQUENCE with type name '[]string'. Then in sbxToUnoValue ( https://opengrok.libreoffice.org/xref/core/basic/source/classes/sbunoobj.cxx?r=a2eaf99e#1310 ), aElemType is retrieved from the '[]string' string (using typelib_typedescription_getByName). Then the obtained typelib_TypeClass_STRING is used to retrieve SbxVariableRef for each element of the sequence (array), using sbxToUnoValue for the elements - and that naturally fails for the elements that are *not* strings.

So the question is - why p is still '[]string' after split, i.e. what is different compared to the other (commented out) way of array creation (we should improve the fix for tdf#144924 in that regard). I assume that at some point, it should change the eType in SbxArray stored in the SbxValue.aData.pObj of the 'p'.