Hi Eike,
On Thu, 2008-12-18 at 16:39 +0100, Eike Rathke wrote:
> 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 don't thin k the "formula" is different. (The meaning and/or result of
the formula of course is different.) Note that I am not saying that
Gnumeric's behaviour is desirable, but I believe it to be compliant.
This may just be a reason to change the openformula draft.
>
> > 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.
This thread is the result of a disagreement about the need to know the
grid size used by the application.
> Not argue about
> which application is compliant and which is not.
Sorry, I didn't see this as an argument about applications but only used
their behaviour differences to point out that their is some problem with
the standard, especially id we do not know the grid size....
> 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.
indeed
Andreas
>
--
Andreas J Guelzow