RE: [office] Data Grid Size element proposal

[Doug Mahugh <Doug.Mahugh@microsoft.com>]

Warren, it's clear that you don't agree with the reasoning that has led several other implementers to conclude that a grid-size element would be useful, but you've not answered my question about what problems you feel the addition of this element would cause.  Do you have a specific argument against the proposal itself?

It seems to me that an optional element which multiple implementers find useful is worth considering as an addition, barring a specific reason that it would cause problems.

Thanks,
Doug

-----Original Message-----
From: Warren Turkal [mailto:turkal@google.com]
Sent: Monday, November 24, 2008 12:45 PM
To: Andreas J Guelzow
Cc: office@lists.oasis-open.org
Subject: Re: [office] Data Grid Size element proposal

On Fri, Nov 21, 2008 at 20:30, Andreas J Guelzow
<aguelzow@math.concordia.ab.ca> wrote:
> On Fri, 2008-11-21 at 18:09 -0800, Warren Turkal wrote:
>> I don't really see the problem with an error being caused by a
>> reference to a cell outside the user agent's range going away when
>> opening the doc in a user agent with a greater number of cells. I
>> could only see that mattering if you rely on the error for some logic
>> in your spreadsheet. That just seems like a bad idea.
>>
>> But maybe I am being dense here. If so, could you please give a
>> concrete and real world example?
>
> Let's see:
> The following formula is from
> http://theimmersivelife.blogspot.com/2008/08/tools-of-trade-google-apps-as.html
> =ARRAYFORMULA(OFFSET(A1,INT(MAX(NOT(ISBLANK(C3:C200))*(COLUMNS($B1:
> $IW1)*ROW(C3:C200)+COLUMN(C3:C200)))/COLUMNS($B1:
> $IW1))-1.0,MOD(MAX(NOT(ISBLANK(C3:C200))*(COLUMNS($B1:
> $IW1)*ROW(C3:C200)+COLUMN(C3:C200)))/COLUMNS($B1:$IW1),1.0)*COLUMNS($B1:
> $IW1)-1.0))
>
> This formula is invalid in Gnumeric with its default grid size but would
> be valid with a larger gridsize. Suppose a program with a larger
> gridsize saves this formula, it would be useful if gnumeric could easily
> determine that the sheet comes from such a larger grid.

Couldn't Gnumeric tell if the formula referred to cells outside it's
gridsize? It seems like it could just notify the user if a cell is
addressed that isn't within it's grid size.

Wouldn't Gnumeric know if a sheet was loaded that had values outside
it's gridsize? It seems that information would already be in an ODS
file. For instance, if Gnumeric could only load 256 columns and a
value for the cell "$IW$1" is defined in the file, wouldn't it be
possible for Gnumeric know that it couldn't address that cell?
Wouldn't it be good to notify the user the the file being loaded had
data that cannot be addressed or saved in that case?

> http://groups.google.com/group/How-to-Documents/browse_thread/thread/1f3ab6e086392bd4 seems to do some similar.

This isn't depending on the error at all. It seems to be depending on
functionality of Google Spreadsheets allowing addressing of cells out
of its range. For instance, I can have up to 256 that I can address
and update. If I do put "=IW19*3" (column 257, row 19) in a cell
though, I get 0 instead of some error. I don't think this situation
makes a case for the explicit maximum size.

> Moreover, the code in
> http://www.excelforum.com/excel-programming/584805-run-time-error-1004-a.html
> would not have shown that error in a gridsize larger than 256 columns.

So what. The user was misusing the function by swapping the order of
the arguments in some VBA code. He wasn't depending on the error for
some kind of logic. The error message wasn't even really a help in
finding what was wrong. Instead, the realization that the arguments
were swapped fixed the issue. I don't see how this is an argument for
having an explicit max columns.

wt

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php