XPost: alt.windows7.general
Newyana2,
But just imagine doing that on a folder with *lots* of files, or better
yet : on a remote computer (with a slow connection) ...
I don't see a problem.
I see several. The above one as the most relatable.
I just ran it on a folder full of XP SP2 files. About 480 files.
I agree that if you take just a few files and doing a single retrieval you won't notice the delay. IOW, "works well enough for home use".
Have you ever done any SQL ? The guys monitoring performance will not like
it when you ask the database for every record, and than just iterate thru results yourself to find the single record you're interrested in. To me
this is the same.
And In that regard I've always wondered why the filesystem object doesn't
allow filename filtering (using wildcards). Sometimes I only need to see
files with a specific extension, but I have to do that filtering myself. On
my local machine. Without any kind of wildcard comparision. With the filenames possibly coming from a (slow) remote computer. It just kills me
to see that kind of waste. :-(
I don't see how you're going to make it simpler. A FolderItem
is part of a collection of what's in a folder.
The funny thing that you can do this :
set objFSO = CreateObject("Scripting.FileSystemObject")
set oFile = objFSO.GetFile(strFile)
It just happens to return the wrong type of file-object.
There's no method like GetFolderItem(path).
As I could not find such a method myself that (its absense) is all I wanted
to verify.
A warning, though: Shell.app is connected with Explorer. It's extremely buggy. On some Windows versions it won't see hidden files or system files.
Thanks for the warning. I might just write my own ActiveX object for the purpose (was already doing that, but came across some VBScript code and just had to check it out - and noticed it doesn't return the "keywords" field in image files. :-().
I just tested the script on System32 and it didn't work. Apparently Win10 won't let shell.app look in system32!
I seem to remember that Win10 has a number of virtual folders (more than XP
or Win7 I mean). Could that be the cause ?
The only other thing I can think of that might be cleaner would
be to use a basic file system methods, then maybe read the data out
by direct binary access.
Yep, that was what I was thinking of. I already did something like it
years ago, but never as an ActiveX component. *And*, I could than add
stuff to write properties too.
Then again, if you want fast then you're not using VBScript. :)
:-p Thats no reason to make it even slower.
Even FSO works fine in System32 on Win10. I can access a file and check
file object properties.
It works as dependable on XP. At least, I've never had any problems with
it, and I've used it quite a bit.
But then you'd need ffmpeg or a binary read or some such to get EXIF data.
... or I read the file as an VT_UI1 array and write a number of methods to extract different sizes of data from it. Bytes, words, quadbytes, byte and
wide strings, etc.
You want slow ? We can make it slow ! :-)
(I might just do that to see if it works and how slow it gets - and than
never look at it again)
Regards,
Rudy Wieser
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)