Bug 146873

Summary:	Macro: bug in CoreReflection after Split() + arrayed( Array() )
Product:	LibreOffice	Reporter:	Kamil Landa <kamlan>
Component:	BASIC	Assignee:	Not Assigned <libreoffice-bugs>
Status:	UNCONFIRMED ---
Severity:	normal	CC:	andreas.heinisch, mikekaganski
Priority:	medium
Version:	7.4.0.0 alpha0+
Hardware:	x86-64 (AMD64)
OS:	Windows (All)
Whiteboard:
Crash report or crash signature:		Regression By:
Attachments:	OK in Watch, but error in CoreReflection

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
	s="a-b-c"
	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
	oReflection=CreateUnoService("com.sun.star.reflection.CoreReflection")
	o=oReflection.getType(p) 'Error
	msgbox o.TypeClass 'if OK it shows 20
End Sub

bug:
Version: 7.4.0.0.alpha0+ (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 7.0.4.2:
Version: 7.0.4.2 (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'.