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 Wed, Nov 26, 2008 at 04:45, Eike Rathke <erack@sun.com> wrote:
> People do have the strangest ideas when "designing" spreadsheets..

True that.

> Andreas already gave examples where formulas would evaluate to
> a non-error in a larger grid size.

To be fair, I asked for a real world example where it matters. The
examples produced previous to this one have demonstrated swapping
arguments in a function and non-compliant ODF behavior. They weren't
issues that'd be improved with the proposed change. I think your
following example might have been alluded to, but it certainly wasn't
so clearly explained.

> Let me add another not so obvious
> example not involving errors at all, which is with the defined named
> ranges I already mentioned that wrap around the sheet's edges when used
> with different offsets, which users may or may not be aware of,
> I suspect most aren't but some may use it as an obscure feature.
> [The entire idea of this wrap-around IMHO was bad from the beginning,
> but ...]
>
> - In an application that supports 256 columns maximum, e.g. Excel2003 or
>  Calc2.4, enter the following values in cells:
>
>   A1: 1
>   B1: 2
>  IU1: 4
>  IV1: 8
>
> - Position the cell cursor on C2.
> - Open the Define Names dialog (menu Insert->Name->Define or such).
>  - Define a name MYNAME and as the reference define A1:B1, note the
>    relative addressing without preceding $ characters.
> - In cell C2 enter the formula =SUM(MYNAME), result is 3.
> - In cell A2 enter the formula =SUM(MYNAME), result is 12.
>  - That is the wrap actually results in the range IU1:IV1, you may
>    easily see if you invoke the Define Name dialog again on cell A2 and
>    look at the definition of MYNAME.
>
> Now if this file was loaded in an application that supported more
> columns without knowing the original maximum grid size, the formula in
> A2 would yield 0 because the range wrapped pointing to then empty cells.

I see. Now that's an interesting example. Thanks for coming up with
this example. :)

> What applications actually can or should do about this is beyond the
> scope of the file format standard, nevertheless it seems to be a good
> idea to include the hint of the original grid size.

I can totally see the use of defining a max col/row for the purpose of
consistent formula evaluation for formulas involving named ranges with
relative addressing in a backward compatible way. I have a couple
questions:
1) Is this wrapping behavior with named ranges defined in the
standard? If so, should we consider removing that behavior in the next
major revision of ODF?
2) Assuming we go forward with this idea, what other questions do we
need to answer about the behavior? I see at least the following:
- What happens when a file is opened and has the attributes defined
but has a different cell dimension? Should the app notify the user?
Should the app limit the interface to only providing the the dimension
declared in the file if the dimension is equal or smaller (in both
directions) than what is native for the app?
- What happens when a file is saved in another application with
different grid size?

BTW, I still don't see the need for the heuristics in determining
whether a style needs to be applied to the whole row based on those
attributes. I still think that is a pretty hacky solution.

wt


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