https://bugs.documentfoundation.org/show_bug.cgi?id=93264
--- Comment #7 from Alex <alex6...@postedmail.net> --- I think Marcelo's observation is slightly different, although no less valid. What I reported had to do with the case of an entire row or column, and the implied need (which had already been recognized by the developers of Calc and addressed with version 5) for being able to specify it without reference to the first or last column of a row, or the first or last row of a column. Marcelo's situation, as I understand it, is different in that he wants less than an entire row or column, but wants the upper end of that partial row or column to be whatever the sheet's last possible range is. One could "fix" the case he gives by having Calc automatically check the last row or column of a named range whenever it was being expanded, and not allow the upper range to exceed the sheet's maximum. However, if -- instead of inserting new rows or columns -- he deleted rows or columns from such a range, Calc would have no way of knowing to keep the named range at its max value, and so would reduce the upper value by as many rows or columns as were removed. So, it seems to me that the user would have to have some way of indicating, when a named range was being created, that the range extended to the last possible row/column, and was to be maintained as such despite subsequent insertion or removal of columns/rows. Whereas an entire column can now (as of version 5) be specified as "$A:$A", what Marcelo seems to be implying is that something equivalent to "$A3:$A" needs to be recognized as a column beginning at row 3 and extending all the way to the last possible row of the sheet, and retained as such despite supsequent insertions or deletions of interim rows. I don't know if present versions of Excel can handle this, but the old version 5.0 of Excel that I continue to use (even under Wine and Linux) can't handle it. I will add that expecting a user to specify the last possible row or column by its actual value is unreasonable because (1) who can remember such values, and (2) these limits could change with future versions. So, to properly address the situation Marcelo describes requires a new accepted syntax for so indicating an upper column/row limit. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs