how to make a search in a hard disk using visual basic 6 - Programmers Heaven

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

how to make a search in a hard disk using visual basic 6


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

Comments

  • BitByBit_ThorBitByBit_Thor Posts: 2,444Member
    :
    : 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

  • GenjuroGenjuro Posts: 913Member
    : :
    : : 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.
  • BitByBit_ThorBitByBit_Thor Posts: 2,444Member
    : : :
    : : : 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

  • the walrusthe walrus Posts: 249Member
    you can always go the DOS route

    (i think the ShellAndWait is infidels.. atleast i got it from one of his posts)
    [code]
    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
    [/code]

    there are better ways to go on production apps, but for home use this is a really easy way :-)
  • BarkeeperBarkeeper Posts: 335Member
    [b][red]This message was edited by Barkeeper at 2005-2-22 2:44:40[/red][/b][hr]
    [b][red]This message was edited by Barkeeper at 2005-2-22 2:41:7[/red][/b][hr]
    Or you can just use, what Windows is already providing, namely API.
    AND YES, RECURSION IS THE KEY TO THAT!

    [code]
    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
    [blue] These are needed Declarations

    Following is a bit of Code i used in a Program i wrote[/blue]

    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

    [blue]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:")[/blue]

    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

    [/code]

    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





  • GenjuroGenjuro Posts: 913Member
    : : : :
    : : : : 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:
    [code]
    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
    [/code]

    (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.
  • BitByBit_ThorBitByBit_Thor Posts: 2,444Member
    :
    : 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:
    : [code]
    : 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
    : [/code]
    :
    : (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

  • BarkeeperBarkeeper Posts: 335Member

    : :
    :
    : 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

  • GenjuroGenjuro Posts: 913Member
    :
    : : :
    : :
    : : 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.
  • BarkeeperBarkeeper Posts: 335Member

    : "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

Sign In or Register to comment.