XPost: alt.windows7.general   
   From: address@is.invalid   
      
   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: you cannot sedate... all the things you hate (1:229/2)