|Summary:||Add class for cell addresses which don't have the concept of absolute/relative references or sheets|
|Product:||POI||Reporter:||Javen O'Neal <onealj>|
|Component:||SS Common||Assignee:||POI Developers List <dev>|
|Bug Depends on:|
Description Javen O'Neal 2015-11-23 09:24:27 UTC
The concept of a cell reference and a cell address are distinct. A cell can identify itself with a cell address, such as CTCell.getR(). A cell address plus a sheet address can identify a particular cell in a workbook. A cell address does not have the concept of being (row or column) absolute or relative, nor does it need to know the sheet that it refers to. On the other hand, a formula (cell formula, array formula, conditional formatting) needs the concept of absolute or relative because the formula may be shifted and we need to know what parts of the formula should be shifted. In a way, a cell address is just a row-absolute column-absolute cell reference with a null sheet, printed without the dollar signs, but it seems better to have two distinct classes for this. Why is a new class needed? If I have two comments anchored at the same CellReference, but one CellReference is relative while the other is absolute, the CellReference won't *equal* each other, even though conceptually they do (since comment anchors don't have a concept of relative/absolute). However, if I could return a CellAddress for the comment anchors, the equals method on two cell comments anchored at the same location would always behave as expected (so long as I know that the two comments are on the same sheet).
Comment 1 Javen O'Neal 2015-11-23 09:43:45 UTC
Thanks for the patch from Hannes Erven submitted in bug 58365, contained in attachment 33143 [details]. Added in r1715743, plus unit test for new CellAddress class. JavaDocs updated r1715746.
Comment 3 Nick Burch 2015-11-23 21:19:30 UTC
If someone has time - it might be worth reviewing all the uses of CellReference in the codebase, and checking if any of those could be swapped over. I have a hunch that there might be one or two places which were just using CellReference because there wasn't an alternative...