Re: [office] Data Grid Size element proposal

[Eike Rathke <erack@sun.com>]

Hi Andreas,

On Tuesday, 2008-12-16 10:04:34 -0700, Andreas J. Guelzow wrote:

> > 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.

So a user may even not notice that the formula is different from the
original and produces a different result. What may be even worse, when
saved again the formula would also be different, but still valid. How
does that make Gnumeric being compliant?

> 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. 

Then it seems we need a definition what should happen with references
pointing outside the actual grid of the application. Not argue about
which application is compliant and which is not. If a document is loaded
in a smaller grid than it was created with, data outside the actual grid
will be lost as well and applications probably will warn the user about
that data loss. The user needs to be informed which of the formula's
references actually caused the #REF! error, doing that by changing the
corresponding part in the formula so far to me seemed to be a good
approach. There may be better means by using tool tips or whatever and
keep the formula intact. However, saving the document again would leave
a broken document that when loaded again in a larger grid would produce
different results because the formula would be valid but the data gone.
Not a solution either.

  Eike

-- 
 OpenOffice.org / StarOffice Calc core developer and i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS

PGP signature