16384 bug
 

Does anyone know a good way to distinguish between XLOPERs based on
A1:A16384 and XLOPERs based on A:A?

In Excel 97, When MS extended the number of rows from 16384 to 65536,
they failed to update some things. For either A1:A16384 or A:A, the
XLOPER has rwFirst=0 and rwLast=16383.
http://groups.google.com/groups?selm...E%40wanadoo.fr

When rwFirst=0 and rwLast=16383 (but not for any other range of 16384
rows, coercion from a reference to xltypeMulti returns a 1x1 array
containing the #NUM! error, so that FuncSum(A1:A16384) from Generic.xll
returns #NUM! even if all cells in the range contain valid numbers.
This is a safe approach if A1:A16384 cannot be distinguised from A:A.
If they can be distinguished, then with A1:A16384, A1:A16385 could be
coerced and the final row ignored.

This problem does not impact SUMPRODUCT, so my current assumption is
that it does not impact any native Excel functions that fail with a full
column. If anyone knows differently, I would appreciate an example.

Note that A1:A16384 is processed correctly if passed as an OPER, which
is yet another reason to use OPERs instead of XLOPERs when possible.

Jerry