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

Reply via email to