[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Data Grid Size element proposal
On Mon, 2008-12-01 at 11:28 -0800, Warren Turkal wrote: > On Sat, Nov 29, 2008 at 10:15, Andreas J Guelzow > <aguelzow@math.concordia.ab.ca> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]