Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On 07/25/2013 05:57 AM, pierre-yves.samyn@laposte.net wrote:
Hello All

Message du 23/07/13 19:46
And the original goal of my post was to figure out whether there are
people who use it, and if yes, what proportion of users (roughly), and
whether or not their use cases could be possibly fulfilled by either
named ranges or database ranges. Somehow I'm not getting any feedback
on that front.

I do user support and training for (thirty) years.
I've never met one user of this feature.
Ok.  Thanks a lot for providing a data point.  This helps.


However, and this goes against the opinions already given,
I found that the "automatic find label" option *is* used.
which really bothers me. We should at the very least turn this off by default, and work toward deprecating this in the future (as Eike also pointed out).

Any objection to that?  Anyone?


Two concrete use cases (where the find label option has an advantage
over "named ranges"):

1. Managing the expansion of the range.

The formula =SUM('Sales'), where 'Sales' is the header column,
will update if you add amounts. To achieve the same result with
a "named range" you must either use a "dynamic" name (calculated)
or plan ahead more than is actually filled range.
Not currently, but the named range can be expanded to add that capability.

Having said that, the expansion of a range sounds more fit for a database range than a named range. I'm now more leaning toward database range as a possible replacement for the labeled range feature.


2. Adaptation of References

A table with two columns: "purchases" (column A) and "sales" (column B)
C1 =SUM('Purchase')
Copy C1 to D1 provides automatically =SUM('Sales') in D1
Good point. If we don't do this currently with named or database ranges, we can add this capability to cover this use case.


This can not be obtained directly if "Purchase" is a named range
(and if the "find label option" is deleted/disabled).
Probably not. But if/when we implement enhanced database range, this use case will likely be covered.


Do not get me wrong: I do not defend at all costs to maintain
this feature. I only see it is used and benefits.
This helps, as I was also looking for the missing pieces that the labeled range provides, so that we can cover those missing pieces in the other existing range features by extending them. Looks like it's plausible to extend the database range to cover these missing pieces.

Thanks a lot for your feedback.

Kohei

--
Kohei Yoshida, LibreOffice Calc hacker, SUSE.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.