Xojo.IO.FolderItem.Count

In my ongoing brave quest to use the new framework wherever possible, I came across the need to count files within a folder today. No problem, we use Xojo.IO.FolderItem.Count, right?

From the docs: [quote]The number of items in the FolderItem if it is a folder. If the item is not a folder then it returns 0.[/quote]

So how does one check if the count is actually zero? If it returns a zero, it means either there are no files in this folder, or this is not a folder. So that’s not much use, is it? And surely, in new framework-style, for consistency, this should throw an exception anyway? I thought the name framework was trying to get away from returning random numbers to signify errors.

So how do you count the number of items, reliably, in a folder in the new framework? It’s an Iterator, so I could use that and count them manually, but what’s the point of the .count property then? I’ve hesitated to post this as I feel like this is so blindingly obvious that I must be missing something due to tiredness.

Dim file As Xojo.IO.Folderitem

If file.IsFolder Then
If File.Count <> 0 Then
' It's not an empty folder...

else
'it's an empty folder

end if

else 
'it's a file

end if

I didn’t used this for now, but i see it has a property “IsFolder” and “Exists”, they must be enough to decide if is a folder or other type and if folder, if empty Count=0.

For us newbies it will be great if FolderItem.Count return > 0 if the folder has files, 0 if folder is empty and -1 if it is not a folder.

You won’t be hold back to file a feature request for it.

Sure, you could use .IsFolder but if you have to do that before checking .Count, then why does .Count return zero for a folder? It doesn’t make any sense to me.

Well if you have a folder you might want to know if it’s empty? How would you know it was empty if it was 1-based and 1 would mean there is 1 item inside the folder?

edit; if you had a file selected instead of a folder and it gives you a count, that would be odd or a bug perhaps?

Because a folderitem can be either a file or a folder. All the docs are saying is that if you happen to query the Count property of a file, it will always return zero. Files can’t contain other files.

It seems inconsistent with the new goals of the new framework, no? Zero can either signify “this is a folder and there are no children” or it can signify “error, this is not a folder”. Shouldn’t it throw an exception?

I think of this more like not a problem, but it might sound more true if it would trow an exception perhaps. Will be hard to decide since greg noted It can be a File or a Folder. So you might need more exception types then you might want?

My non-programmer logic thinks that if folderitem is a file, then the count should be 1.
My newbie-programmer logic thinks that if folderitem is a folder and it is empty it should be 0, so folderitem.count should not report 0 in other instances.

[quote=358726:@Alberto De Poo]My non-programmer logic thinks that if folderitem is a file, then the count should be 1.
My newbie-programmer logic thinks that if folderitem is a folder and it is empty it should be 0, so folderitem.count should not report 0 in other instances.[/quote]

There is no “FolderItem” in a “File” so giving count 1 if it’s a file makes no sense.
It might make sense to report Xojo.IO.FolderItem.Count = -1 once it is a File instead of a Folder.
Still reporting 0 when it’s a file makes the most logic solution.

Count is “how many items does this thing contain”
A directory (folder) may container 0
A file definitely “contains” 0 other files

So 0 for count makes sense in either case
But to answer the question “does this directory contain any files” a single number cannot tell you that

  1. it IS a directory
  2. it does/does not contain other files & dirs

So you do need 2 properties - Count and IsFolder

[quote=358730:@Derk Jochems]There is no “FolderItem” in a “File” so giving count 1 if it’s a file makes no sense.
It might make sense to report Xojo.IO.FolderItem.Count = -1 once it is a File instead of a Folder.
Still reporting 0 when it’s a file makes the most logic solution.[/quote]
You are right, it makes no sense if count is 1, because the question is “how many items does this thing contain”, that’s why I said how people with no programming skills may think about a count property. I was thinking more like “how many files this file contains”? and I’m sure a non-programmer will say 1 most of the time.

[quote=358733:@Norman Palardy]Count is “how many items does this thing contain”
A directory (folder) may container 0
A file definitely “contains” 0 other files

So 0 for count makes sense in either case
But to answer the question “does this directory contain any files” a single number cannot tell you that

  1. it IS a directory
  2. it does/does not contain other files & dirs

So you do need 2 properties - Count and IsFolder[/quote]

Thank you, I do understand the logic of having 2 properties, Count and IsFolder. I was thinking more like:

  • a file definitely “contains” 0 other files
  • if I put some code that asks the count, the programmer knows that a file contains 0 other files
  • so maybe the programmer what really wants is to know how many items are in a folder
  • but if the count return 0 for empty folder and 0 for file, he needs another property to really know if the item is a folder
  • if count return -1 for files, 0 for empty folders and a number with the items in a folder, then there is no need to check if the item is a folder

I’m in not way trying to change the logic here. Just want to learn how things are done. In this thread I learned that you need IsFolder when the Count is 0, to know if the folderitem is a folder of a file. Thank you.