Apache OpenOffice (AOO) Bugzilla – Issue 10798
Parameter passing / SUMIF doesn't accept same type
Last modified: 2013-08-07 15:12:27 UTC
I don't know if this is a problem with the StarBasic parameter values or the SUMIF function. If you have either of the following two Macro functions (StarBasic), and I tested both to check for conversion problems: Function PassThru( Val As Object ) PassThru = Val End Function Function PassThru( Val As Variant ) PassThru = Val End Function And then create two SUMIF statements, such as: =SUMIF( D2:D10; "EUR"; C2:C10 ) =SUMIF( PASSTHRU(D2:D10); "EUR"; C2:C10 ) The first statement should work as normal, but the second statement, with the call to passthru produces an "Err:504", yet the PassThru function should not have changed the type of the object. This makes it impossible for a StarBasic macro to interact with the SUMIF function in a transparent manner -- that is, in the same way it interacts with the other functions such as SUM.
This is not a bug of the Basic. VAL is a function and therefore could not be used as a variable. So this is invalid. Frank
sorry reopening as this seems to be nonsens.
seems to be a scripting problem. So I set the flags and reassign it.
Andreas, please have a look at this and target accordingly.
-> OOo 2.0
cp: retargeted to Office-Later due to limited ressources
fst is right, VAL should not be used. But also with Function PassThru( aVal As Variant ) PassThru = aVal End Function I get the "Err:504". -> nn: aVal contains a SbxDimArray with lbound = 1 and ubound = 9 (by the way: accessing the array elements fails for some reason). I could not detect any error situation in Basic when executing the function PassThru and SbMethod::Call() also returns no error. So I don't know where "Err:504" comes from. Please have a look.
The Basic function works without problems and returns an array. But SUMIF (and similar functions) accepts a cell range only, not an array-type intermediate result. This is a limitation that might be changed at a later time, but it works as described (the help specifies "cell range"), so it's not a defect.
Accepting issue. In general, most functions that work on a cell range should also accept an intermediate array as parameter, except a few that need cell positions or database ranges.
I agree with the comments made, but the original defect I reported still exists. The problem is *NOT* that SUMIF does not take an array (though that may well in itself be another issue). The problem is that the PassThru function is changing the type of variable. If SUMIF on D2:D10 works, that means D2:D10 is a CellRange as is explained that SUMIF works only on CellRange. Then, PassThru takes a Variant, so in this case we should be expecting an Object (of type CellRange). Then we simply return that type, and SUMIF should use it happily since we have *not* modified the type. Yet, it fails, since somewhere in the chain the CellRange was converted to an array, yet it was not the StarBasic code that did it. This is the defect I wanted to report, SUMIF was just an example to demonstrate the error.
Mortoray, StarBASIC spreadsheet functions always receive arguments per value, in case of a cell range as an array of copies of cell values. It is not a CellRange object, and returned in your case is an array. The problem *IS* that SUMIF does not take an array. Eike
Setting duplicate to an issue that is more concise and to the point. *** This issue has been marked as a duplicate of 65866 ***
Closing dup.