Ok... i got to bring up the counter point here. how many of us
really roll our codebases from one version of RB to the next without
having to track down new issues and code around them? so heres my
ugly ugly solution (this will take a few releases of RB):
add a folderitem.ubound method which returns count -1. deprecate
folderitem.count (but obviously keep it for old code)
define and *well* document that folderitem.item(0) returns the same
item as folderitem.item(folderitem.count)
now, we can start using folderitem as 0 based, old code continues to
run, and we can slowly build up a year or so of versions of RB which
will play well with code once .count is removed entirely.
could work??
mike
--
Mike Woodworth
[EMAIL PROTECTED]
On Oct 6, 2006, at 3:15 PM, [EMAIL PROTECTED] wrote:
On Oct 06, 2006, at 17:11 UTC, John Balestrieri wrote:
In 2006r3 under OSX (carbon PEF) FolderItem.Count is returning the
Ubound of the folder items.
I'm not sure what you mean by that. It should return the number of
items in the folder.
So rather than intuitively looping from 0 to FolderItem.Count-1, I
have to loop from 0 to FolderItem.Count. Can anyone jog my memory.. I
can't recall if this is the correct behavior or not?
No, you should loop from 1 to FolderItem.Count. FolderItem.Count is
one of those historical leftovers that is 1-based, and changing it
would break too much code. Note that FolderItem.Item(0) is undefined;
it happens to return the folder itself on my machine, but on other
machines or in other versions it may not do that, so you should avoid
using it.
Best,
- Joe
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
