#1   Report Post  
Posted to microsoft.public.excel.sdk,microsoft.public.excel.programming
external usenet poster
 
Posts: 837
Default 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
Search this Thread:

Advanced Search
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
VLOOKUP in large Data sets of more than 16384 rows Bluewolf Excel Worksheet Functions 11 April 3rd 06 09:39 PM
importing accounting data am limited to 16384 line - why? bob@applied Excel Discussion (Misc queries) 2 September 6th 05 04:35 PM


All times are GMT +1. The time now is 03:32 AM.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 ExcelBanter.
The comments are property of their posters.
 

About Us

"It's about Microsoft Excel"