Issue 85000 - ODFF: SUMIF's 3rd parameter is handled differently from Excel
Summary: ODFF: SUMIF's 3rd parameter is handled differently from Excel
Status: CLOSED FIXED
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: 680m241
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: oc
QA Contact: issues@sc
URL:
Keywords: ms_interoperability
Depends on:
Blocks:
 
Reported: 2008-01-04 19:06 UTC by kyoshida
Modified: 2013-08-07 15:15 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
test case (24.00 KB, application/vnd.ms-excel)
2008-01-04 19:08 UTC, kyoshida 		no flags Details
patch to fix this issue (2.33 KB, patch)
2008-01-04 21:37 UTC, kyoshida 		no flags Details | Diff
revised patch to fix the crash. (2.63 KB, patch)
2008-01-07 18:57 UTC, kyoshida 		no flags Details | Diff
let's switch to using MAXCOL and MAXROW instead of MAXCOLCOUNT and MAXROWCOUNT. (2.57 KB, patch)
2008-01-07 21:07 UTC, kyoshida 		no flags Details | Diff
TestCaseSpecification (6.68 KB, text/html)
2008-02-28 08:03 UTC, oc 		no flags Details
Testdocuments for Test Case Specification (15.65 KB, application/vnd.oasis.opendocument.spreadsheet)
2008-02-28 08:04 UTC, oc 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description kyoshida 2008-01-04 19:06:31 UTC 
In Calc, SUMIF's 3rd parameter expects a cell range, and Calc expects the
geometry of that cell range to match that of the 1st parameter.

In Excel, however, the 3rd parameter's range geometry does not have to match the
1st parameter's; Excel takes the upperleft cell address and use the geometry of
the 1st parameter to turn that into a cell range.
Comment 1 kyoshida 2008-01-04 19:08:19 UTC 
Created attachment 50667 [details]
test case
Comment 2 kyoshida 2008-01-04 21:37:53 UTC 
Created attachment 50670 [details]
patch to fix this issue
Comment 3 kyoshida 2008-01-04 21:38:27 UTC 
changing issue type to PATCH
Comment 4 mmeeks 2008-01-07 10:50:32 UTC 
also good for usability IMHO, I managed to screw up my SUMIF regions to not be
exactly the same size (by 1 row), and was stumped for quite a while just the
other day.
Comment 5 ooo 2008-01-07 11:42:43 UTC 
In cws odff:

sc/source/core/tool/interpr1.cxx  1.51.38.5
Comment 6 ooo 2008-01-07 13:19:21 UTC 
Actually there was more to it. Excel silently ignores out-of-sheet-bounds
conditions if the resulting range would exceed max columns or rows, e.g.
SUMIF(A1:B2;1;IV65536) does not complain but would at most sum cell IV65536. The
attached patch even crashed under that condition. Btw, nCol4,nRow4,nTab4 weren't
needed at all.

sc/source/core/tool/interpr1.cxx  1.51.38.6
Comment 7 kyoshida 2008-01-07 18:22:48 UTC 
Yeah I noticed the crash.  It's pretty bad.

I'm on my way to fixing it.  Thanks for pointing that out.
Comment 8 kyoshida 2008-01-07 18:57:31 UTC 
Created attachment 50721 [details]
revised patch to fix the crash.
Comment 9 ooo 2008-01-07 19:43:35 UTC 
Yes, shrinking the source range is the better approach.
sc/source/core/tool/interpr1.cxx  1.51.38.7

Btw, MAXCOLCOUNT - 1  is identical to MAXCOL ;-)
Comment 10 kyoshida 2008-01-07 19:47:30 UTC 
>Btw, MAXCOLCOUNT - 1  is identical to MAXCOL ;-)

Doh!  It was just a few lines down from MAXCOLCOUNT! ;-)
Comment 11 kyoshida 2008-01-07 21:07:11 UTC 
Created attachment 50723 [details]
let's switch to using MAXCOL and MAXROW instead of MAXCOLCOUNT and MAXROWCOUNT.
Comment 12 ooo 2008-02-19 18:19:00 UTC 
Reassigning to QA for verification.
Comment 13 oc 2008-02-28 08:03:58 UTC 
Created attachment 51778 [details]
TestCaseSpecification
Comment 14 oc 2008-02-28 08:04:41 UTC 
Created attachment 51779 [details]
Testdocuments for Test Case Specification
Comment 15 oc 2008-02-28 08:05:47 UTC 
verified in internal build cws_odff
Comment 16 oc 2008-10-17 10:37:10 UTC 
closed because fix available in builds OOO300_m9 and DEV300_m33