[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: . . . named ranges in Siag--Further clarification -Reply
>>> James Ramsey <firstname.lastname@example.org> 09/30/98 11:50pm >>>
>Let me do a more concise clarification of my proposal for named ranges
>The essence of my proposal was to find an intelligent way to implement
>named ranges in Siag so that the name of the range would actually
>refer to the data it was supposed to refer to. The reason I proposed
>storing the named range in some sort of array is that this way, even
>if the placement of the data on the spreadsheet grid were to change,
>the range name would still refer to the data it was intended to refer
Acceptable and potentially interesting *if configurable.*
>I know that most commercial spreadsheets are 'smart enough' to adjust
>the cell references appropriately when the range is repositioned, but
>it still seems like the spreadsheets still 'think' of the range as
>refering to a set of cells in the spreadsheet rather than refer to the
>data that those cells contain. I simply wanted to propose an alternate
And the "other method" indicates where my concern would lie...
Your proposal essentially "nails down" the references to cells. If the cells
get spread apart, the references also spread apart.
This is certainly a neat idea.
Unfortunately, it means that managing any changes to the range becomes much more
In the "traditional" naming approach, one might have a range called "Sales
Details" containing sales by department and period. If you add some additional
rows/columns within that range, the range automagically expands to include the
With your approach, something special (and I'm not sure of the user interface)
has to be done to do this expansion.
Making the range "fixed" in the fashion you describe is more meaningful if there
is an explicit model associated with the spreadsheet.
<http://users.ox.ac.uk/~popx/mm.html> describes a scheme (Model Master) where
spreadsheets are constructed using an explicit model produced in a simple
If you plan to "fix" the ranges, I would contend that you need to simultaneously
"free" them via using something like Model Master to describe them in a way
that makes that ability for values to shift to be usefully managed.