Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.excel.sdk,microsoft.public.excel.programming
|
|||
|
|||
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 |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
VLOOKUP in large Data sets of more than 16384 rows | Excel Worksheet Functions | |||
importing accounting data am limited to 16384 line - why? | Excel Discussion (Misc queries) |