OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Data Grid Size element proposal

On Tue, 2008-12-16 at 12:49 +0100, Eike Rathke wrote:
> Hi Andreas,
> On Tuesday, 2008-12-02 10:05:15 -0700, Andreas J. Guelzow wrote:
> > > > > OO.o 3.0 since it has more columns.
> > > > > 
> > > > > A1..E1 contain 1..5.
> > > > > AMJ is the last colume.
> > > > > A2 is set to "=AMJ1" and copied to B2..E2.
> > > > > 
> > > > > A1 = 0 and B1..E1 say "#REF!" and are set to "=REF!".
> > > > 
> > > > So the users asked OOo to copy a formula and OOo silently changes the
> > > > formula into an error string _without_alerting the user?
> > > 
> > > The result displays #REF!, which is a standard error displayed for
> > > references errors.
> > 
> > My copy of OOo 3.0 does _not_ display #REF! just as a result but in fact
> > it changes the formula entered to "=REF!". (If it just showed the result
> > of #REF! I could go in and modify the reference. This way I cannot.)
> Almost true. To be exact, the part that lead to the reference error is
> set to #REF!, here the column, so it is =#REF!1  (row 1 is kept intact).
> The behavior is similar to what Excel does, just that Excel does not
> distinguish sheet/col/row parts and unconditionally modifies the formula
> to =#REF! instead.
> > Note that OpenFormula draft requires that if the reference is beyond the
> > capabilities of the application the reference should evaluate to REF! I
> > ma wondering what OOo would do would it encounter this in a file and the
> > file is being saved without user modification. Would it change the
> > formula?
> No, the formula would be saved "as is", including the '#REF!'.
> > Since the OpenFormula draft refers to capabilities (and not gridsize) I
> > consider Gnumeric compliant with the draft in this respect (using a
> > toroidal grid) while OOo  is not.
> I don't get that. Why would Gnumeric be compliant with the draft when
> wrapping references while copying cells? And why would OOo not be
> compliant when it does not?

My reading of the standard is:

if the reference is "beyond the capabilities" of the application it
should _return_as_value an error but of course it should retain the
formula as is since without user interaction the formulas ought to be
saved as they were in the file when opened.

if the reference is not "beyond the capabilities" then of course we are
just using it...

Clearly the reference I was talking about is beyond the capabilities of
the Openoffice and it changes the formula to another formula, so it is
not compliant.

Gnumeric handles the reference by interpreting it on a toroidal grid, so
the reference is not beyond its capabilities  and so there is no need to
return an error.

I suspect that your understanding of "beyond the capabilities" is
different from mine (namely that you think that this reference ought to
be beyond Gnumeric's capabilities if its number of column is too small)
but I did not find any definition of this in the standard. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]