Re: Named expressions change after entering them.

Jody Goldberg writes:
On Fri, Oct 19, 2001 at 10:26:52PM -0700, Jacob Burckhardt wrote:

I think you are implying that relative to the current edit cell is a
bad thing.  But I think that is a good thing.  Having it be relative
to the current cell lets me refer to cells to the left of that current
cell.  I cannot do that if the reference point is always A1.  I will
use an example to elaborate on this and explain why this is important:

Although I am not a fan of this idiom I understand what it can do.
However. to support it and avoid the issue you mention in
requires that we store the edit position when the name was defined.
This is easy for gnumeric but I'll need to experiment with XL
import/export to see how they handled it.  MS XL does not seem to
store that information, which forces us to parse relative to A1.

Actually, you could still *parse* relative to the current cell, but
*store* relative to A1.  This means you do not have to "store the edit
position when the name was defined."  For example, if you select cell
C2 and create a name called RightRef, with expression D2, then gnumeric
should store the expression as B1 since cell B1 is one cell to the right
of cell A1.  Then if you put =RightRef in cell M4, then gnumeric knows
that it will mean that it should refer to the cell to the right which
in this case would be cell N4.

Of course this still has the problem of how do you *store* a leftward
reference.  You could come up with some new notation like maybe
"column=-1,row=0" which means the column which is one column to the
left of cell A1 and 0 rows away from cell A1.  If you had to document
this notion so that users could use it, then it might be a difficult
problem to create a notation which would be understandable to users.
But this is not something users have to know about.  Only the gnumeric
developers have to know about it since it only involves how you
*store* the named expression.  Users do not have to know about it
since if the user wants a left ward reference, he simply moves to cell
C2, and creates a name with an expression of B2.  You may store it as
"column=-1,row=0", but the user does not know that.  The user only
knows of it as B2.

BTW, if you decide to implement it this way, there is another detail
to take care of: If the user creates a name and then moves to a
different cell and then edits the name, be sure to adjust the relative
cell references to be based off of a reference point of the current
edit cell.  For example, if you move to cell C2 and press Control-F3,
and select RightRef, it should show D2, but if you later move to cell
M4 type Control-F3, and select RightRef, it should show an expression
of N4.  This is like the more familiar behavior of copying a relative
cell reference from one cell to another cell.  The benefit of doing
this is that the user can select *any* cell which uses the named
expression, type Control-F3, and then very easily see which cells the
expression references.  This way, the user does not have to do any
translation in his head.  The spreadsheet program should translate for

I'm sorry I picked a bad title for my bug report you mentioned above.
I titled it "Named expressions change after entering them."  Above I
have advocated doing the very thing my title complains about.  I
should have clarified that I don't want them to change if I edit from
the same cell from which I created.  That's the case the bug report
describes.  If I edit from a cell *different* than the cell where I
created, then I do think that relative references in the expressions
should change as described above.

Named expressions are the weakest segment of gnumeric.  I'll put
some work into them shortly, but in general you can assume that we
are aware of the bugs there.  It is the only place in gnumeric with
known crashable features, which puts it fairly high on the priority

Thanks.  I appreciate it being high priority since it is a feature I
use a lot in other spreadsheet programs.

gnumeric-list mailing list
gnumeric-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]