i am trying to build a program that scans all the harddisk for a file using Microsoft Visual Basic 6,i am using the dirlistbox control to find the directories,but the problem is that the dirlistbox control do not show the hidden folders,even if i choose to show the hidden files and folders from the tools menu,please if you can help me to find a way to let the dirlist control shows the hidden directories,
or if there is another way to find in all the directories including the hidden directories.

Best Regards

:
: i am trying to build a program that scans all the harddisk for a file using Microsoft Visual Basic 6,i am using the dirlistbox control to find the directories,but the problem is that the dirlistbox control do not show the hidden folders,even if i choose to show the hidden files and folders from the tools menu,please if you can help me to find a way to let the dirlist control shows the hidden directories,
: or if there is another way to find in all the directories including the hidden directories.
:
: Best Regards
:

Use the Dir function. With the first call supply the information through the arguments. Then, to find the rest, use Dir without arguments. You'll need to set up a loop of some sort (or maybe create a function that continues to call itself)

Greets...
Richard

: :
: : i am trying to build a program that scans all the harddisk for a file using Microsoft Visual Basic 6,i am using the dirlistbox control to find the directories,but the problem is that the dirlistbox control do not show the hidden folders,even if i choose to show the hidden files and folders from the tools menu,please if you can help me to find a way to let the dirlist control shows the hidden directories,
: : or if there is another way to find in all the directories including the hidden directories.
: :
: : Best Regards
: :
:
: Use the Dir function. With the first call supply the information through the arguments. Then, to find the rest, use Dir without arguments. You'll need to set up a loop of some sort (or maybe create a function that continues to call itself)
:
: Greets...
: Richard

I wouldn't.
A recursive function calling Dir() with parameters would reset the dir call; so once the function returns, the parent function's Dir() would b screwed up.
Besides, I find it's easier to use the FileSystemObject for these task.

: : :
: : : i am trying to build a program that scans all the harddisk for a file using Microsoft Visual Basic 6,i am using the dirlistbox control to find the directories,but the problem is that the dirlistbox control do not show the hidden folders,even if i choose to show the hidden files and folders from the tools menu,please if you can help me to find a way to let the dirlist control shows the hidden directories,
: : : or if there is another way to find in all the directories including the hidden directories.
: : :
: : : Best Regards
: : :
: :
: : Use the Dir function. With the first call supply the information through the arguments. Then, to find the rest, use Dir without arguments. You'll need to set up a loop of some sort (or maybe create a function that continues to call itself)
: :
: : Greets...
: : Richard
:
: I wouldn't.
: A recursive function calling Dir() with parameters would reset the dir call; so once the function returns, the parent function's Dir() would b screwed up.
: Besides, I find it's easier to use the FileSystemObject for these task.
:

I refuse to use the filesystem object, especially if it is not for home usage. But even if it is, I wouldn't. I am sure there is a way of either using loops or recursive function calls to find all the files you need.

Greets...
Richard

you can always go the DOS route

(i think the ShellAndWait is infidels.. atleast i got it from one of his posts)

Private Declare Function OpenProcess Lib "kernel32" (ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessID As Long) As Long
Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long
Private Declare Function WaitForSingleObject Lib "kernel32" (ByVal hHandle As Long, ByVal dwMilliseconds As Long) As Long

Public Sub ShellAndWait(ByVal strCommand As String, Optional ExecMode As VbAppWinStyle = vbMinimizedNoFocus)
On Error GoTo ProcedureError
Const kstrProcedureName = "ShellAndWait"
    
    Dim ProcessID As Long
    Dim hProcess As Long
    Dim hWnd As Long
    Dim ret As Long
    
    'start the process
    ProcessID = Shell(strCommand, CLng(ExecMode))
    
    'wait for the process to finish
    hProcess = OpenProcess(&H100000, False, ProcessID)
    ret = WaitForSingleObject(hProcess, -1&)
    
    'close the process handle
    CloseHandle hProcess

ProcedureExit:
    On Error Resume Next
    Exit Sub
    
ProcedureError:
    'need to re-raise the error to the calling procedure in the appropriate format
    Select Case Err.Number
        Case Else           'exception raised in code
            Err.Raise Err.Number, Err.Source, Err.Description
    End Select
    Resume ProcedureExit
    Resume

End Sub


Private Sub Command1_Click()

    Dim Results As String, ff As Long, FindFile As String
    
    FindFile = "command.com"

    ChDrive "c"
    ChDir "c:\"
    Command1.Enabled = False
    Command1.Caption = "Searching..."
    ShellAndWait "cmd /c dir /s /b /d /x " & FindFile & " > c:\dir.out", vbHide
    Command1.Caption = "Search"
    Command1.Enabled = True

    ff = FreeFile
    Open "c:\dir.out" For Binary As #ff
        Results = String(LOF(ff), Chr(0))
        Get #ff, , Results
    Close #ff

    MsgBox Results

End Sub

there are better ways to go on production apps, but for home use this is a really easy way

This message was edited by Barkeeper at 2005-2-22 2:44:40

---

This message was edited by Barkeeper at 2005-2-22 2:41:7

---

Or you can just use, what Windows is already providing, namely API.
AND YES, RECURSION IS THE KEY TO THAT!

Public Declare Function FindFirstFile Lib "kernel32" Alias "FindFirstFileA" (ByVal lpFileName As String, lpFindFileData As WIN32_FIND_DATA) As Long
Public Declare Function FindNextFile Lib "kernel32" Alias "FindNextFileA" (ByVal hFindFile As Long, lpFindFileData As WIN32_FIND_DATA) As Long
Public Declare Function FindClose Lib "kernel32" (ByVal hFindFile As Long) As Long

Public Const MAX_PATH = 260
Public Const INVALID_HANDLE_VALUE = -1

Public Type FILETIME
  dwLowDateTime As Long
  dwHighDateTime As Long
End Type

Public Type WIN32_FIND_DATA
  dwFileAttributes As Long
  ftCreationTime As FILETIME
  ftLastAccessTime As FILETIME
  ftLastWriteTime As FILETIME
  nFileSizeHigh As Long
  nFileSizeLow As Long
  dwReserved0 As Long
  dwReserved1 As Long
  cFileName As String * MAX_PATH
  cAlternate As String * 14
End Type

Dim colFiles as Collection
 These are needed Declarations

Following is a bit of Code i used in a Program i wrote

Private Sub Search(ByVal SearchPath As String)
Dim Found As WIN32_FIND_DATA, Retval As Long, hFile As Long


'Search for the first file
    If Mid(SearchPath, 2, 2) = ":\" And Len(SearchPath) = 3 Then
  
        hFile = FindFirstFile(SearchPath & "*.*", Found)
          ' If no file found then cancel
        If hFile = INVALID_HANDLE_VALUE Then
          MsgBox "This Folder contains no Files", _
            vbInformation, "Cancel search"
          Exit Sub
        End If
  
    Else
  
        hFile = FindFirstFile(SearchPath & "\*.*", Found)
          ' If no file found then cancel
        If hFile = INVALID_HANDLE_VALUE Then
          MsgBox "This Folder contains no Files", _
            vbInformation, "Cancel search"
          Exit Sub
        End If

    End If

You could think why there is the same code twice. It isn't. You have to differ between "normal" Folders to start your search in and the Root-Folder (i.e. "c:\")

  Do
    Select Case CBool(Found.dwFileAttributes And vbDirectory)
      Case True 'Found a Folder
        
        dummy = Left$(Found.cFileName, InStr(1, Found.cFileName, vbNullChar) - 1)
          
        If dummy <> "." And dummy <> ".." And Mid(SearchPath, 2, 2) = ":\" And Len(SearchPath) = 3 Then
            
            colFiles.Add SearchPath & dummy
        
            Search SearchPath & dummy
            
        ElseIf dummy <> "." And dummy <> ".." And Len(SearchPath) > 3 Then
            
            colFiles.Add SearchPath & "\" & dummy
        
            Search SearchPath & "\" & dummy
            
        End If
        
      Case False 'Found File
          
        dummy = Left$(Found.cFileName, InStr(1, Found.cFileName, vbNullChar) - 1)
                  
            If Len(SearchPath) > 3 Then
            
                colFiles.Add SearchPath & "\" & dummy
            
            Else
        
                colFiles.Add SearchPath & dummy
            
            End If
            
'        End If
        
    End Select
    ' Search next File
    Retval = FindNextFile(hFile, Found)
    DoEvents
  Loop Until Retval = 0
  FindClose hFile
  
  MsgBox "Found: " & colFiles.Count & " Files"
  
End Sub

This Code-Example is searching all Folders and Subfolders from a given Startfolder (given in the SearchPath-Argument when calling the "Search"-Sub), so you might use the API "BrowseForFolder" to define a Folder to start with.

If you're searching for a particular File or a pattern in the filename, you can alter the Search-pattern ("*.*" in the example) or just filter the Results in the Collection (Check out the InStr-Function)
------------------------------------------
Only stupidity of mankind and the universe
are infinite, but i'm not sure concerning
the universe. A. Einstein

: : : :
: : : : i am trying to build a program that scans all the harddisk for a file using Microsoft Visual Basic 6,i am using the dirlistbox control to find the directories,but the problem is that the dirlistbox control do not show the hidden folders,even if i choose to show the hidden files and folders from the tools menu,please if you can help me to find a way to let the dirlist control shows the hidden directories,
: : : : or if there is another way to find in all the directories including the hidden directories.
: : : :
: : : : Best Regards
: : : :
: : :
: : : Use the Dir function. With the first call supply the information through the arguments. Then, to find the rest, use Dir without arguments. You'll need to set up a loop of some sort (or maybe create a function that continues to call itself)
: : :
: : : Greets...
: : : Richard
: :
: : I wouldn't.
: : A recursive function calling Dir() with parameters would reset the dir call; so once the function returns, the parent function's Dir() would b screwed up.
: : Besides, I find it's easier to use the FileSystemObject for these task.
: :
:
: I refuse to use the filesystem object, especially if it is not for home usage. But even if it is, I wouldn't. I am sure there is a way of either using loops or recursive function calls to find all the files you need.
:
: Greets...
: Richard
:

Of course there's one: first use Dir() and set parameters for it; then copy all the directories/files in two arrays, then iterate over each one again, consuming heaps of memory and CPU time in the process, and, once recursion gets deep enough, you also have good chances of the stack blowing out due to the larger memory footprint; moreover, I find that pretty annoying and error-prone.

While I know the limits of the FileSystemObject, I still prefer:

Function RecurseIterateFolder(ThisFolder as Folder)
Dim SubFolderObj as Folder
Dim FileObj as File

for each FileObj in ThisFolder.Files
    'do what you need
next
for each SubFolderObj in ThisFolder.Subfolders
    'perhaps skipping "." and "..", I can't remember
    call RecurseIterateFolder(SubFolderObj)
next
End function

(note that I wrote those two lines right here and now, without trying them, so they might contain some silly errors and whatnot)

I just can't find any good reason to complicate things so mercilessly on oneself as to write things another way.
Compare this piece of code and others' in this thread, and tell me which one is easier and takes less time to code and debug.

But then, it's a matter of tastes.

:
: Of course there's one: first use Dir() and set parameters for it; then copy all the directories/files in two arrays, then iterate over each one again, consuming heaps of memory and CPU time in the process, and, once recursion gets deep enough, you also have good chances of the stack blowing out due to the larger memory footprint; moreover, I find that pretty annoying and error-prone.
:
: While I know the limits of the FileSystemObject, I still prefer:
:

: Function RecurseIterateFolder(ThisFolder as Folder)
: Dim SubFolderObj as Folder
: Dim FileObj as File
: 
: for each FileObj in ThisFolder.Files
:     'do what you need
: next
: for each SubFolderObj in ThisFolder.Subfolders
:     'perhaps skipping "." and "..", I can't remember
:     call RecurseIterateFolder(SubFolderObj)
: next
: End function
: 

:
: (note that I wrote those two lines right here and now, without trying them, so they might contain some silly errors and whatnot)
:
: I just can't find any good reason to complicate things so mercilessly on oneself as to write things another way.
: Compare this piece of code and others' in this thread, and tell me which one is easier and takes less time to code and debug.
:
: But then, it's a matter of tastes.
:

I just don't like using even more external libraries.
I wonder how much memory the FileSystem Object consumes when you use this method...

Greets...
Richard

: :
:
: I just don't like using even more external libraries.
: I wonder how much memory the FileSystem Object consumes when you use this method...
:
: Greets...
: Richard
:
:
Exactly the same with me. If i can find a solution with API, i just put the code into a standard-Basic-Module, and code a Wrapper around. Coded once, used a lifetime! No need for external libs.
------------------------------------------
Only stupidity of mankind and the universe
are infinite, but i'm not sure concerning
the universe. A. Einstein

:
: : :
: :
: : I just don't like using even more external libraries.
: : I wonder how much memory the FileSystem Object consumes when you use this method...
: :
: : Greets...
: : Richard
: :
: :
: Exactly the same with me. If i can find a solution with API, i just put the code into a standard-Basic-Module, and code a Wrapper around. Coded once, used a lifetime! No need for external libs.
: ------------------------------------------
: Only stupidity of mankind and the universe
: are infinite, but i'm not sure concerning
: the universe. A. Einstein

And I agree also - although I don't like APIs at all (I got so tired of writing code with APIs that I stopped using VB and begun using C++: if I need to code half of my code in APIs, I might as well give up the workarounds).
About memory consumption, I am pretty sure that the FileSystemObject uses way less memory for the calls itself - besides 'stack' and 'memory' are different matters (what I mean is, on a computer with 2GB RAM, I still have only one MB dedicated to each program's stack).

"No need for external libs"? Wow, now that's a funny one. Are you referring about the DLLs you call through APIs, or the FileSystemObject (which is part of the operating system from Win98 and later)? Or perhaps to the VB runtime? Look at it any way you like, you are using some anyway. And I've yet to see a VB6 program which needs no external libs. Well, I've yet to see any Windows program which needs none.

To Richard: about *stack* memory consumed using that method, it just encapsulates FindFirst and FindNext API calls better (allowing a kind of "object instance FindFirst handle", so to say), so it's significantly less than storing recursively a list of directory names in a Unicode array; I'm pretty sure of it.
And okay, objects consume heap memory space, but I wouldn't compare a File Object to a string, if you know what I mean.

: "No need for external libs"? Wow, now that's a funny one. Are you referring about the DLLs you call through APIs, or the FileSystemObject (which is part of the operating system from Win98 and later)? Or perhaps to the VB runtime? Look at it any way you like, you are using some anyway. And I've yet to see a VB6 program which needs no external libs. Well, I've yet to see any Windows program which needs none.
:
Right. i see your point. maybe i haven't made clear what i mean. What i mean is, that there are a lot of VB-People who don't have a clue, what Windows is doing or even providing. Since i started using API-calls i have a much more deeper understanding what is going on during a Code-Run. Sure, the FSO is part of the OS, as much as the other libs used by VB like the runtime, but unexperienced programmers will always provide a unnecessary bunch of dll's in their setup's, which isn't needed. Also, there is always a chance, that a Windows-Setup is axed, and the particular dll is missing. You never know.

And let's just leave it there. Let's just agree, that we disagree :)
------------------------------------------
Only stupidity of mankind and the universe
are infinite, but i'm not sure concerning
the universe. A. Einstein