I run this code and get a nil object on the last item
itemF is the folder
var fcnt As Integer = itemF.Count
fSerch = fdirs(fdirs.LastIndex)//or the filename being looked for
For i = 0 To fcnt
If itemF.ChildAt(i).Visible And fSerch = itemF.ChildAt(i).Name Then
Return 0
End If
Next
Whatever file could throw a nil object for equating the name, but be visible?
You can’t have i go from 0 to itemF.Count – off-by-one error. You want to initialize it to itemF.count-1. Count is the number of items, but they are indexed from 0 to Count-1.
Not sure what it has to do with .DS_Store, but yes, that’s invisible in the Finder but will still show up if you iterate over all of the items in the folder this way.
I was surprised it didn’t explicitly say that, but the ChildAt docs do call it an index and the examples all use .ChildAt(0) so one could infer the first entry is zero and indeed your code block starts at zero. So from 0 to itemF.Count would indeed attempt to access one index position too many.
In API 2 – where ChildAt() was introduced – Xojo has standardized on starting with 0 which is actually an improvement in consistency versus API 1 where the similar property was .Item() and started at 1 while some other things started at 0.
So in API 2 – what you should be using now for new code, expect things to start at 0 unless you very explicitly see it telling you otherwise. You may find code samples in older code which do have loops starting at 1 instead of 0. But you’ll find they use different names (like this .ChildAt vs the prior .Item) or a string substring using .Mid – which is 1-based – versus the API 2 .Middle which is 0-based.
Hope this helps – it is meant in a spirit of helping you with similar things in the future.