Bug 55050 - Creating a new AreaPtg from an existing instance on same row/column inverts the "absolute" row/column attribute
Summary: Creating a new AreaPtg from an existing instance on same row/column inverts t...
Alias: None
Product: POI
Classification: Unclassified
Component: XSSF (show other bugs)
Version: unspecified
Hardware: Macintosh All
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Reported: 2013-06-03 11:16 UTC by Christopher Brown
Modified: 2014-07-31 16:07 UTC (History)
1 user (show)

Proposed test case for this issue (1.01 KB, text/plain)
2013-07-03 10:55 UTC, Christopher Brown

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brown 2013-06-03 11:16:59 UTC

I have a formula in an xlsx worksheet, opened as SUM($D$2:D2), which during processing the logic of my program "stretches" it to a column further to the right (depending on what data I'm adding to the worksheet).  I'm expecting it to be (for example) "stretched" to SUM($D$2:Q2).

What I'm observing is different, I get SUM($D2:Q$2).  In other words, the "absolute" row reference has "moved" from the first column to the last column, when I specifically constructed the replacement AreaPtg instance to retain the absolute markers.  I've tracked this down to the constructor in:

protected AreaPtgBase(int firstRow, int lastRow, int firstColumn, int lastColumn, boolean firstRowRelative, boolean lastRowRelative, boolean firstColRelative, boolean lastColRelative)

...which inverts the attributes of lastRow and firstRow if the lastRow isn't after the first row.  I understand that this is trying to "sanitize" bad parameters, however it appears to incorrectly handle the case of firstRow and lastRow being equal, and inverts the "absolute" attribute incorrectly.

Here's my sample code:

_ptgs[i] = new AreaPtg(
 aptg.getFirstRow(), aptg.getLastRow(), firstColumn, lastColumn,
 aptg.isFirstRowRelative(), aptg.isLastRowRelative(), aptg.isFirstColRelative(), aptg.isLastColRelative()

Comment 1 Nick Burch 2013-06-03 11:28:51 UTC
Any chance you could turn this into a failing unit test? (That'll make the process of fixing it, and ensuring it stays fixed much quicker)
Comment 2 Christopher Brown 2013-06-03 11:58:57 UTC
I could try to create the unit test... I've never fixed anything on an Apache project, so I'm unfamiliar with the conventions.  How would I go about it: do you have an example of how to run it and a pointer to a subversion folder where it would be recommended to put this test?

It looks as if the fix could be as simple as changing the comparison operator in both "if" blocks in the constructor to use the ">=" (greater than or equals) operator instead of the ">" (greater than) operator.
Comment 3 Nick Burch 2013-06-12 17:30:29 UTC
http://poi.apache.org/guidelines.html has some guidance

A unit test will normally live in the same package as the thing it tests, but in a different folder (eg src/testcases/org/apache/foo vs src/java/org/apache/foo)

If you're having issues, best ask for advice on the dev list
Comment 4 Christopher Brown 2013-07-03 10:55:05 UTC
Created attachment 30529 [details]
Proposed test case for this issue

Here's the test case, I think you'll need to deal with adding it to the source tree as I'm not a committer.

Each of the four assertions fails, obviously with the first one failing, the next ones can't run.
Comment 5 Nick Burch 2014-07-31 16:07:01 UTC
Thanks for the test, I've used it in r1614928 to fix the problem