On Mon, 2008-12-01 at 11:28 -0800, Warren Turkal wrote:
> On Sat, Nov 29, 2008 at 10:15, Andreas J Guelzow
> <> wrote:
> >
> >
> > I don't really care whether you and your coworkers have previously seen
> > something. I have just used a default sized Gnumeric to create the
> > following spreadsheet:
> >
> > A1 to E1 contain the integers 1 through 5
> > A2 contains "=IV1" and this is copied into B2 to E2.
> >
> > As a consequence E2 shows the value 4.
>
> I can't replicate this behavior in OO.o 3.0. Here's the what I did in
> 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?
>
> I believe that OO.o will produce similar results using =IV1 in A1 in
> OO.o 2.4.x, but I don't have a copy installed on the computer I am on.
>
> So, I guess my next question is is the behavior defined by the spec.
> If so, which (OO.o or Gnumeric or neither) is compliant to the spec?
>
> > Now this spreadsheet exists in the real world (and has nothing to do
> > with named ranges.)
>
> So I just found that OO.o doesn't do that, so it's not a global issue.
It is interoperability issue.
>
> I personally find OO.o's behavior in this situation much more helpful
> than magically wrapping the references.
silently changing the content of what is being copied?
I guess I could have thought of that: if OOo doesn't do X why would
anyone want X?!
Andreas Guelzow
PS: I read the list. Please stop sending me duplicate messages.
