https://bugs.documentfoundation.org/show_bug.cgi?id=174283
Andreas Bertsatos <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|[email protected] |[email protected] |desktop.org | --- Comment #2 from Andreas Bertsatos <[email protected]> --- Thanks for the pointer, Ben. I built your chain (211470, 211474 and 211471 at patch set 11) and tried it with octave-calc: =OCTAVE("magic", 3) still shows only 8, the top-left value, where =SEQUENCE(3, 3) spills. As far as I can tell, the decision to spill is taken before the call, in intendsArrayResultInRange() in sc/source/core/data/formulacell.cxx, and an ocExternal call always counts as a single value there. Your chain changes how the call is made, but not that decision. I have a patch for it: the walk counts an Add-In call as an array when its function is declared to return one of the array sequences or a FormattedResult, and a function declared to return any stays a single value, so existing Add-Ins behave as before. I cherry-picked it onto your chain and its unit test passes there as well, so the two should not get in each other's way; whichever lands second needs only a rebase. It is up as https://gerrit.libreoffice.org/c/core/+/213395 and I have added you as a reviewer, since you know that walk from the LET and LAMBDA work. One thing your chain may make easier later: a call inside a function that takes a single value, such as =ROUND(OCTAVE("magic", 3); 0), still does not spill, because an Add-In reports no return class to the compiler the way the built-in array functions do. ScExternalFunction::GetParamClass() looks like the natural place to give it one, but that would change how existing formulas calculate, so I have left it out of this patch. -- You are receiving this mail because: You are the assignee for the bug.
