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:
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) )
msgbox o.TypeClass 'if OK it shows 20
Version: 184.108.40.206.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
but for example OK in 220.127.116.11:
Version: 18.104.22.168 (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
We changed split in https://gerrit.libreoffice.org/c/core/+/123122, thid could affect the core reflection. I have to test it though.
@Mike: Should we allow in  also non fixed variant arrays? Since the new split function  resets the fixed flag and changes the type to variant? Imho the GetByte function should allow all kind of retrievals.
(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'.