Hello!
What's the reason only ReadFolder() returns a proprietary FolderEnum object, while everywhere else Collections are used? Latter can be used "regularly" with the standard Enumerator of JScript to access tab/folder items (like in Func.Tab.All e.g.). I find myself mixing things up and wonder why FolderEnum needs to be there at all? Do you know? o)
Thanks!
To return a collection it would have to read the entire folder before returning, and depending on the size of the folder that could take a lot of time and memory when you might only want the first name. Imagine how long a recursive read of C:\ would take and how much memory would be required.
Ah I see!
FolderEnum.next() does the actual work of getting item details by each call and ReadFolder() does not really scan the filesystem beforehand. That makes sense. So FolderEnum.next() should also come across files added to the filesystem, after ReadFolder() was called to create FolderEnum?
Thank you! o)
I wouldn't rely on it seeing, or not seeing, files made after the enum begins. The OS may take a snapshot of the dir and use that for the enum, or it may not. It may also vary for different types of folder (e.g. zip files).
Can I use the Enumerator on the FolderEnum and get the same results as using it on selecteditems?
Try it and see, but I don't think so. The FolderEnum object works slightly differently to a normal collection/enumerator, for performance reasons.
yeah it doesn't work.
I had to basically dump files using folderenum and then use new enumerator on it