I often want to scream about not being successful at finding something at
MSDN that I know should be there. My current beef is that MSDN won't let me
see/download the Vista Recover CD ISO file that Microsoft worked so hard to
create, for those whose computer manufacturer failed to provide this
function on a bootable CD/DVD. I did find the download here:
http://neosmart.net/blog/2008/window...disc-download/, but it
requires Torrent. That turned out to be relatively easy and I have the ISO,
but not directly from Microsoft, so I have less confidence in its validity.
I went to your msdn link, and found that it pertains to the FolderItems
object. On the left side of the that page is a header item "Shell Objects
for Scripting ..." which is truncated to "Shell Objects for" when IE6's text
size is set to what I am comfortable with. I guess Microsoft hasn't learned
enough about HTML and style to build web pages that make adjustments for IE
user's preferences. Or maybe this is just a way to prod people to the
latest IE.
The Folder item in the list probably describes the members of the original
shell folder. The Folder2 item in the list describes the all the members of
the shell folder, implemented by some newer DLL. Not listed is a Folder3
item that my WXP SP3 has, which further extends the members of shell
folders.
Filter is a method of a folder items collection, so you should find it
within one or more of the three FolderItems links on the left side of the
page you referenced. FolderItems3 seem to be the first one to implement the
Filter method and is the newest one reported by TLViewer on my system.
On the folder size issue, since a folder window does not display its
subfolder's sizes, the shell.application folder cannot give that info.
Thanks for sharing your reasons for distrusting shell.application.
-Paul Randall
"mayayana" <mayaXXyana@xxxxxx> wrote in message
news:uzR05%23S9JHA.4944@xxxxxx
Quote:
> Interesting. I was about to say that I've
> never heard of Filter. It turns out this isn't
> the first time I've never heard of Filter. 
>
> http://groups.google.com/group/micro...ript/browse_th
> read/thread/25b9de6a9d2721ec/033406db000254b6
>
> But it's not in my older copy of MSDN. It's not
> on my system (Win98SE). And I don't see it on
> the MSDN page:
>
> http://msdn.microsoft.com/en-us/libr...00(VS.85).aspx
>
> Unfortunately, while MS used to be very thorough
> about listing libraries and versions that support
> a specific method, object, interface, etc., they seem
> to have stopped doing that. But I'm assuming the link
> above is the latest version.
>
> So apparently Filter works starting with some shell
> version after 98SE, but is undocumented? It's an
> interesting method. If dependable then it seems to
> be a powerful, easy way to list specific file categories.
> But for me, at least, if it's not on all Windows versions
> then I try to avoid it. I like to stick to code that I know
> is dependable on Win9x up.
>
> I've been wary of using Shell because it's really
> dealing with display rather than the file system.
> So it seems like it's asking for trouble to enumerate
> files with it. I've never systematically mapped out
> the abberations. I originally noticed it because I
> had written a custom folder.htt on Win98 and added
> a function to list files. At some point I noticed that
> hidden files and "system-type" files were missing from
> the list, even though my settings were to show all
> files. I found that at least .DLL and .DRV files were
> being left out. On XP I haven't seen that, but I did
> find that hidden files were left out and that the Explorer
> view settings had no effect on that. Another quirk is
> that folders show 0 size. (I don't know if that's true
> on all Windows versions.)
>
> So I figure that it's better to just stick with something
> like FSO when dealing with the file system, but of course
> that's not feasible if one is doing something that only
> shell can do, like checking extended properties of files
> on XP.
> Quote:
>> I'm working (occasionally) on a script that recurses through all folders
> on Quote:
>> a drive that are accessible to the FSO, and which compares the folder's
>> files and subfolders collections to the items available in the equivalent
>> shell folder items collection, noting the things that are in one of the
> two Quote:
>> objects (fso vs shell.app) and not in the other. So far I have found
>> that
>> shell.app folders do not reveal hidden items, even though the items
>> collection filter property has a masking bit associated with 'hidden',
>> according to the MS Online docs. Maybe I haven't figured out how to use
>> this 'hidden' bit.
>>
>> Do you have a script that demonstrates the 'undependable tool'
> shortcomings Quote:
>> that you talk about, on WXP? I don't have an older system to play on.
>> Is
>> it only hidden files or are there others that don't show up for you?
>>
>> Oops. I just tried groups.googling for 'shell folder items filter
>> group:*.scripting.vbscript', and found a sample script that includes the
>> hidden files. Here is the script with a few modifications:
>>
>> Const iFolders = 32, iFiles = 64, iHidden = 128
>> Set oShell = CreateObject("Shell.Application")
>> sPath = "D:\VBScript\Test Filter Hidden"
>> sFilter = "*.txt"
>> Set oFolder = oShell.NameSpace(sPath)
>> Set oFolderItems = oFolder.Items()
>> oFolderItems.Filter iFolders + iFiles, sFilter
>> WScript.Echo "Non hidden filtered .TXT files count = " &
> oFolderItems.Count Quote:
>> oFolderItems.Filter iFolders + iFiles + iHidden, sFilter
>> WScript.Echo "Hidden filtered .TXT files count = " & oFolderItems.Count
>> if oFolderItems.count = 0 then WScript.Quit
>> For Each oItem In oFolderItems
>> WScript.Echo oItem.Path
>> Next
>>
>> I created a single hidden .txt file in the folder with my script, and it
>> produced the following results:
>> Non hidden filtered .TXT files count = 0
>> Hidden filtered .TXT files count = 1
>> D:\VBScript\Test Filter Hidden\New Text Document.txt
>>
>> It seems counterintuitive for the first of the following statements get a
>> collection of all non-hidden files and the second statement to expand
>> that
>> collection to include hidden files while also contracting the collection
> to Quote:
>> only those files with an extension of .txt.
>> Set oFolderItems = oFolder.Items()
>> oFolderItems.Filter iFolders + iFiles + iHidden, sFilter
>>
>> My Shell32.dll is file/product version 6.00.2900.5622, and OS is WXP Home
>> SP3.
>>
>> -Paul Randall
>>
>> "mayayana" <mayaXXyana@xxxxxx> wrote in message
>> news:%23MXbPnQ9JHA.3544@xxxxxx Quote:
>> > Adding to the other posts:
>> >
>> > The FileSystemObject GetFileVersion method
>> > is the easiest, if you just want the file version.
>> >
>> > The WMI method provides more, but not all
>> > version info.
>> >
>> > The Shell.Application method varies greatly
>> > depending on OS. It's also an undependable tool
>> > that does not actually see all files.
>> >
>> > A 4th method is here:
>> > www.jsware.net/jsware/scripts.php5#fvinfo
>> >
>> > It's a VBScript class that you can paste into
>> > any script. It works by "cutting out the middleman".
>> > While each of the above methods calls an
>> > available object to get what that object can provide,
>> > this class reads directly from the file's version info.
>> > section, in the file's resource table. The other objects
>> > get their info. from the same place, with a
>> > sidetrack through the Windows API. By reading from
>> > the resource table directly the class can return
>> > anything that's been recorded there -- including
>> > Comment, FileDescription, etc. -- and not just the
>> > parts made avaiable through a given scripting object.
>> >
>> >
>> >> How do I get the value of the file version or product version property > of Quote:
Quote:
>> > a
>> >> file in a VB script?
>> >>
>> >
>> >
>> >
>>
>> >
>