Results 1 to 9 of 9
  1. #1
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    FileSearch (.FileType ) (Word97SR2 & up?)

    I need help understanding WHY the .FileType seems not to apply in a FileSearch (Word97, but based on my reading of past posts, probably all the way up to Word2005)

    I expect the procedure to find "c:autoexec.bat", but to discover that it is NOT a Word document, and so fail the text, and so return "0" files found.

    Instead it returns "1" files found (Win98SEW/Office97SR2)

    Using .FileName = "*.*" (in an attempt to generalise the search) returns 42 files - I have that many in my root directory.



    <pre>Sub test()

    Dim objFS As FileSearch
    Set objFS = Application.FileSearch

    With objFS

    .NewSearch
    .LookIn = "C:"
    .FileName = "autoexec.bat"
    .FileType = msoFileTypeWordDocuments

    If .Execute > 0 Then
    MsgBox "There were " & .FoundFiles.Count & " file(s) found."
    Else
    MsgBox "There were no files found."
    End If

    End With

    End Sub
    </pre>


  2. #2
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts

    Re: FileSearch (.FileType ) (Word97SR2 & up?)

    Chris,

    This behavior may not be what you expect or wish, but at least it is consistent with the interactive behavior.

    In the File/Open... dialog box, if you select C: in "Search in", AutoExec.bat in "File Name" and Word Documents (*.doc) in "File Type", and click "Find Now", Word will find 1 document. If you leave "File Name" blank, Word will find 0 documents (assuming you have no *.doc in the root of C. Apparently, entering something in "File Name" overrules the entry in "File Type".

    So rejoice - it's not every day you find this consistency between the user interface and VBA!

  3. #3
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: FileSearch (.FileType ) (Word97SR2 & up?)

    Hans, thanks for this response.

    > In the File/Open... dialog box, if you select C: in "Search in", of C<img src=/S/smile.gif border=0 alt=smile width=15 height=15>. Apparently, entering something in "File Name" overrules the entry in "File Type".


    I load Word97/SR2.

    File
    Open
    LookIn "c:"
    FilesOfType "Document templates (*.dot)"
    New Search
    Advanced

    Advanced find GUI shows 1 line added already, that of "Document templates (*.dot)."
    (note that second period!)


    I choose "And, Filename includes, autoexec (no period), Add to list


    Advanced find GUI shows 2 lines, that of "Document templates (*.dot)."
    and that of "File name includes Autoexec."
    (note that period after AutoExec!)


    I choose FindNow and it reports zero files. That's what I'd expect. I don't have any AutoExec DOCument templates in C:. As you might guess, but I must confirm, I have only one AutoExec in the root directory of drive C, that is a text file c:AutoExec.bat.




    Back in Advanced, I delete the 2nd line "File name includes Autoexec." and choose "And, Filename includes, autoexec.bat , Add to list.

    Now the Find reports one file found.



    I'm guessing that if one specifies a perfect match (no masks etc involved), Word says "I already found the file, you didn't need to tell me it was a template". Someone programmed an OR instead of an AND? Or more likely, someone has an ExitFor when they shouldn't have.




    It's most annoying.

    I wanted to use the FileSearch object to tap into all the different File Properties. I already have the file names in a table. The idea was to loop through the table checking properties of the files.
    Why not just revert to the raw FileSearch? because we are making multiple "filter" passes on the files, reducing the set and storing the interim results ("these files have passed all the tests to date") in an internal array, ready for the next round of tests.




    I still have to fathom out this business of FileSearch saving its settings between calls. That may torpedo the whole thing anyway.





    When the application fires up, user has a choice of either (1) start by looking at all files on the hard drives or (2) use an internal array (which can be saved to disk between sessions).

    We want the loop to be:
    <pre> If processing from the hard drives
    use FileSearch object ("a") to retrieve the next file
    else ' we are processing from the saved array
    obtain the next name from the table
    use FileSearch object ("b") to test Fileproperties on this one file
    endif
    ' Now, whichever source of Filename, use FileSearch object to test its properties .....

    </pre>



    I have to see if I can maintain separate FileSearch object by re-instating the conditions at point "a" each time around the loop, because they might have been superseded by the code at point "b".

  4. #4
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: FileSearch (.FileType ) (Word97SR2 & up?)

    > .FileName = "autoexec.bat"
    .FileType = msoFileTypeWordDocuments



    Since posting my experiment with The Interactive, I thought to repeat the experiment with VBA.

    > .FileName = "autoexec*"
    .FileType = msoFileTypeWordDocuments

    Yields me ZERO hits, which is what I expect, but does not solve my immediate problem, that of testing an explicit and uniquely-named filename for a characteristic.

  5. #5
    Silver Lounger
    Join Date
    Jun 2001
    Location
    Morden, Surrey, United Kingdom
    Posts
    1,838
    Thanks
    3
    Thanked 0 Times in 0 Posts

    Re: FileSearch (.FileType ) (Word97SR2 & up?)

    I'm not an expert here, but since Windows (and presumably Word) uses the suffix to decide what type of file it is, having it search for a file including the suffix (.bat) then trying to tell it that you only want Word documents (.doc) is, as far as it's concerned, a contradiction in terms. Presumably it's saying 'you've already specified the type (suffix) (with a more specific request), therefore I'm going to ignore this (less specific) line, since it contradicts the first one'.

    Yes, if you asked a human to give you "all the square ones that are round" they'd say "don't be daft, none of them are square AND round", but this is a computer program; it runs one line at a time. In this case it gives you the square ones then looks blank, shrugs its shoulders and ignores you when asked to pick out the round ones!

    What I'm trying to say (not very clearly!) is, although you've used two different ways of saying it, you're asking for two different items under the same parameter, and as I understand it, computers usually prioritise commands, so giving it a very specific "filename='autoexec.bat'" and then trying to moderate it with the less specific (to it) "filetype=msofiletypeworddocuments" just causes it to choose the more specific (and higher priority) one and use that.

    Am I making sense? <img src=/S/confused.gif border=0 alt=confused width=15 height=20> Maybe I should just go away again ... <img src=/S/sad.gif border=0 alt=sad width=15 height=15>
    Beryl M


  6. #6
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: FileSearch (.FileType ) (Word97SR2 & up?)

    > since Windows (and presumably Word) uses the suffix to decide what type of file it is

    Not quite true. More true to say that one Windows application, Windows File Explorer, makes use of a convention that the extent defines the file type.

    Even that's not true. Nothing to stop you or I assigning the extent EXE to a Corel WordPerfect document type. Silly, but possible. When we install Win98SE, Explorer sets up a slew of extent associations that seem reasonable. That's just to save you and I from laboriously setting them up one by one. The File Associations belong to you and I, not to Windows or any Windows Application. Windows applications use what we own.



    On shakier grounds is any argument that one criteria should nullify another.

    There seems little point in permitting a programmer to specify two distinct criteria and then quietly ignoring one of them. Specifically because Explorer allows re-assignation of extents to file types, the two conditions I mentioned in the first post ought expressly to be testable in conjunction.


    "square" and "round" are specific instances of the same characteristic - 2-dimensional shape. That would be the equivalent of my asking the computer (program) to return all files with an extent of "SQU" whose extent is also "ROU". Can't even program that. (Well, actually, FileSearch does let you do that, but it generates no error at all, at all!)


    In my case I'm asking the analogus of "all the round ones that are blue" (shape Vs. colour) and the computer - the FileSearch object is replying "Don't be silly - the sun is YELLOW".

    Now THERE's silly for you!

  7. #7
    Super Moderator
    Join Date
    May 2002
    Location
    Canberra, Australian Capital Territory, Australia
    Posts
    5,054
    Thanks
    2
    Thanked 417 Times in 346 Posts

    Re: FileSearch (.FileType ) (Word97SR2 & up?)

    Hi Chris,

    I think the problem can be boiled down to the fact that you can't really tell what kind of file you're dealing with unless you open it and search for an identifying marker within it.

    With your original code, I think you're getting a count of 'autoexec.bat' files AND other files associated with Word, whereas what you seem to be saying is that you want to find out how many 'autoexec.bat' files are really Word files.
    Cheers,

    Paul Edstein
    [MS MVP - Word]

  8. #8
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: FileSearch (.FileType ) (Word97SR2 & up?)

    >you can't really tell what kind of file you're dealing with unless you open it

    It's true that, by and large, if I open the file I can determine its type, but surely the purpose of the FileType parameter in FileSearch is that I don't have to open the file in order to see, and I don't have to bother my pretty little head with the internal workings of a Word (or other) document. MSoft knows what they look like and MSoft is prepared to tell me (as per my other post in this thread within a couple of minutes).

    > With your original code,

    My original code assumed that what I'd read in the HELP files meant what it looked like - that if I identified a specific set of files, possibly only one file in the set, and a Type-of-document, FileSearch would tell me whether a file with those characteristics existed.

    It appears not to do that at all.

  9. #9
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: FileSearch (.FileType ) (Word97SR2 & up?)

    I thought about it this weekend.

    This sort of thing sends shivers up my spine.

    The Help files suggest that each test is ANDed, but then I find that for two of the tests - FileType and name - this is not the case.

    It is a simple matter to cobble together a cheap function to satisfy this particular combination - code pasted below - by first ignoring the name and obtaining names of all documents of TYPE, and then testing that collection for NAME.

    To my mind this defeats the purpose of FileSearch as a fast method; I'm now coding an interpreted VBA loop where I shouldn't need to.


    Worse - I might have to implement such a crude scheme for OTHER combinations of conditions.

    Worse still - I would first have to test all combinations exhaustively to see what the HELP files haven't told me. With about a dozen properties (FileLength, Date last modified, FileName Property, FileType Property, LastModified Property, LookIn Property, PropertyTests Property, Application Property, Condition Property, Connector Property, SecondValue Property, Value Property, SearchSubFolders Property, TextOrProperty Property) I might have twelve times eleven pairs to test before I can have a user specify any two properties to be tested in combination.


    That's an awful lot of work thrown onto the coder because the VBA team didn't code an AND statement where they should have.




    <pre>Function blnFileIsOfType(strPath As String, strName As String, lngType As Long) As Boolean
    ' Muscle-flexer to show that MSoft's weird logic CAN be overcome.

    Dim blnResult As Boolean ' Interim result
    blnResult = False ' Default result is "File of this type Is Not Found"

    Dim objFS As FileSearch
    Set objFS = Nothing ' in theory blots out any other serach, including the one that preciptates this oen.
    Set objFS = Application.FileSearch
    Dim lngFound As Long

    With objFS
    .NewSearch
    .LookIn = strPath
    .FileName = "*" ' Initially use a generic name serach to obtain files of TYPE
    .FileType = lngType
    .Execute
    lngFound = .FoundFiles.Count
    End With

    If lngFound > 0 Then ' maybe - just maybe, our specific file is one of them
    Dim L As Long
    L = 1
    While (L <= objFS.FoundFiles.Count) And (Not blnResult)
    If UCase(objFS.FoundFiles(L)) = UCase(strPath & strName) Then
    blnResult = True ' Yes, our specific file is one of them
    Else
    End If
    L = L + 1
    Wend
    Else
    End If

    blnFileIsOfType = blnResult ' Form formal result

    End Function
    Sub TESTblnFileIsOfType()
    MsgBox blnFileIsOfType("d:greavesadmin", "Kayep.doc", msoFileTypeWordDocuments)
    End Sub
    </pre>


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •