https://issues.apache.org/bugzilla/show_bug.cgi?id=56454
Bug ID: 56454
Summary: XSSFSheet.shiftRows(...) and HSSFSheet.shiftRows(...)
incorrectly handle merged regions starting before the
first shifted row.
Product: POI
Version: 3.10
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: XSSF
Assignee: [email protected]
Reporter: [email protected]
Created attachment 31556
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31556&action=edit
Test case demonstrating the problem.
XSSFSheet.shiftRows(...) and HSSFSheet.shiftRows(...) incorrectly handle merged
regions starting above the first row to shift containing the shifted row,
depending on the first column of the merged region.
If the merged region does not contain column 0, the region gets (incorrectly)
shifted.
Consider the following example:
Case 1:
- Create merged region in A2:B5 (starting at row 3 col 0, ending at row 6 col
1)
- Shift row 4 down 1 row: sheet.shiftRows(3, sheet.getLastRowNum(), n);
Case 2:
- Create merged region in B2:C5 (starting at row 3 col 1, ending at row 6 col
2)
- Shift row 4 down 1 row: sheet.shiftRows(3, sheet.getLastRowNum(), n);
Observed Result:
In case 1, the merged region is still starting at row 3. In case 2, it starts
at row 4.
Expected result:
Merged region should still be starting at row 3 in both cases.
The reason for this behaviour is in XSSFRowShifter line 69:
if (!containsCell(merged, startRow - 1, 0) && !containsCell(merged, endRow + 1,
0)) {
The check for column 0 should not be there. Instead, the line should look like
this:
if (!containsRow(merged, startRow - 1) && !containsRow(merged, endRow + 1)) {
A similar check is done in HSSFSheet Line 1286 (using
SheetUtil.containsCell(...)).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
