Find Function Wizard does not enter Array Formula even though it is selected. Entering the formula in formula bar, and using Shift+Ctrl+Enter to complete it, makes it work as expected. https://ask.libreoffice.org/en/question/238949/find-array-function-issue/ https://ask.libreoffice.org/upfiles/1587099935266830.png Version: 6.4.1.2 (x64) Build ID: 4d224e95b98b138af42a64d84056446d09082932 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: en-AU (en_AU); UI-Language: en-GB Calc: threaded
Reproduced in Version: 7.0.0.0.alpha1+ Build ID: 86bc13248c1d9f63b10aac304bdf0361d1dcc47f CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Steps to reproduce: 1. Open Calc 2. Open Formula Wizard 3. Add '=FIND({"A";"B";"C"},"SAMPLE TEXT")' to Formula field
Also reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.19; Render: default; Locale: en-US (en_US.UTF-8)
Not reproducible in Version: 4.4.0.0.alpha2+ Build ID: 3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 Locale: en_US
Bibisected with win 5.0 repo to range https://git.libreoffice.org/core/+log/e360c2a861cc98efab442c58e5c79dab3ac99b8e..b49abbbd9d0107bef93adde32a1b51c78b6df469 Note that Xisco's step 3 can be FIND({"A";"B";"C"};"SAMPLE TEXT") depending on your locale Adding Cc: to Stephan Bergmann
Fairly sure the semi-colon (;) delimiter makes the formula incompatible with MS-Office which I understand uses a comma (,) delimiter.
(In reply to Xisco Faulí from comment #2) > Steps to reproduce: > 1. Open Calc > 2. Open Formula Wizard > 3. Add '=FIND({"A";"B";"C"},"SAMPLE TEXT")' to Formula field What I understand: 1 Open Calc 2 "Insert - Function..." 3 In the "Formula" edit box complete "=" to "=FIND({"A";"B";"C"},"SAMPLE TEXT")", press "OK" 4 The input line erroneously contains "=FIND(#NAME?,"SAMPLE TEXT")" and cell A1 erroneously contains "#NAME?", instead of whatever the correct values should be.
Eike, any idea whether those "Replace remaining getCppuType et al with cppu::UnoType" changes mentioned in comment 5 could plausibly cause this error (or would more likely be pointing at an error in generating the bibisecting repo)? I have no idea at what level things start to go wrong here in the code, and how to debug this issue.
I doubt the cppu type changes are related to this, but I can take a debug approach..
(In reply to flywire from comment #6) > Fairly sure the semi-colon (;) delimiter makes the formula incompatible with > MS-Office which I understand uses a comma (,) delimiter. No, there is no incompatibility here because what's stored in the file format may be different and is defined. The separators used in the UI depend on your locale and your settings under Tools -> Options -> Calc -> Formula, Separators. In MS-Excel you also don't have a comma function parameter separator if your decimal separator is comma.
Seems to be a general failure with inline arrays, enter ={1;2}+3 as array formula, producing two rows with results {4;5} Invoke Function Wizard on that selected formula cell range, Array is checked, Result correctly displayed as {4;5}, hit OK => cell results are #NAME? and formula is =#NAME?+3
Already ={1} is sufficient and formula is =#NAME?
Funny, this indeed may be related to the cppu type changes as we hit https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/token.cxx?r=61d8db6b#1260 where rToken.Data.getValueType() is <cppu::detail::cppu_detail_getUnoType<css::uno::Any>(cppu::UnoSequenceType<css::uno::Any> const*)::p> with *pTypeName: "[][]any" compared with cppu::UnoType< css::uno::Sequence< css::uno::Any >>::get() with *pTypeName: "[]any" which are not equal. That was changed with commit 3f80ac477354f4c6293d983d3ca9eef59a07dce0 CommitDate: Wed Apr 1 08:40:39 2015 +0200 Replace remaining getCppuType et al with cppu::UnoType - else if (!rToken.Data.getValueType().equals( getCppuType( - (uno::Sequence< uno::Sequence< uno::Any > > *)0))) + else if (!rToken.Data.getValueType().equals( cppu::UnoType< + uno::Sequence< uno::Any >>::get())) Not exactly sure why, but if indeed these inline arrays worked in old releases then the previous code may had matched both []any and [][]any or only [][]any.
Ah of course uno::Sequence< uno::Sequence< uno::Any > > is [][]any.
(In reply to Eike Rathke from comment #13) > commit 3f80ac477354f4c6293d983d3ca9eef59a07dce0 > CommitDate: Wed Apr 1 08:40:39 2015 +0200 > > Replace remaining getCppuType et al with cppu::UnoType > > - else if (!rToken.Data.getValueType().equals( > getCppuType( > - (uno::Sequence< uno::Sequence< uno::Any > > > *)0))) > + else if (!rToken.Data.getValueType().equals( > cppu::UnoType< > + uno::Sequence< uno::Any >>::get())) Apparently a typo that slipped in when doing all those changes manually. Thanks for tracking it down!
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5f5afecda386642aabf2365130629b6a237bf953 Resolves: tdf#132173 handle API sequence to inline array token correctly It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/c/core/+/93996 for 6-4
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/905f16f6f0e8ef356bc5fe5a35708b0cc5407135 Resolves: tdf#132173 handle API sequence to inline array token correctly It will be available in 6.4.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.0.0.0.alpha1+ Build ID: 1ffe59ef31186e36ad0aa7bbcdd32e407ee8d26c CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Eike, thanks for fixing this issue!
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1ed7607454d1492f65c78443cb661d5873face6b tdf#132173: sc: Add UItest It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.