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


So...I asked a spreadsheet ninja coworker of mine if they had ever
used the named range wrapping functionality you showed me for anything
use. That person told me that they had never seen it used in the real
world. Considering that it only works on named ranges and not ranges
given in formulas, I am inclined to say that this feature (max row/col
attributes) is still not worth adding unless someone can come up with
a real world example of usage that would be enhanced with its
addition. I don't like the idea of having some magic value that alters
the way the spreadsheet calculates formulas, and I don't think that it
would be a valuable use of the TC's time to define all the corner
cases that result from that feature. I think it will make things
radically more complex for an edge case that rarely (if ever) is
encountered.

Having said all this, I do think that we should consider making named
ranges specifically not wrap. This kind of change may belong in the
next major revision of ODF (2.x?). I think that would be a much more
clean way to address the issues that you brought up.

Thanks,
wt

On Wed, Nov 26, 2008 at 10:03, Warren Turkal <turkal@google.com> wrote:
> 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]