使用 FindNextFile 时按句柄获取搜索路径？

Question

I use FindFirstFile() and FindNextFile() to list files of a directory. When I call FindFirstFile() , I have to give a search path to it. It returns a handle that can be used by FindNextFile() . Is there a WinAPI function that can get the previously given path by the handle?

Answer 1

Just store that information like you store the search handle already: in a variable. Then create your own wrapper functions for both FindFirstFileA() and FindNextFileA() :

type
  // What you want to give back per file system object
  TMyFindInfo= record  // Whatever you want to do here on your own
    wfd: Windows.WIN32_FIND_DATAA;  // Just provide this as-is because it already everything
  end;

  // Not only storing the handle, but also other details
  TMyFindHandle= record
    h: THandle;  // Search resource
    sFilter: String;  // Original query
    iMatches,  // How often did the search yield a file system object?
    iError: Cardinal;  // Which error has occured? 0=ERROR_SUCCESS.
  end;

function MyFindFile1st
( const sFilter: String
; out vInfo: TMyFindInfo
): TMyFindHandle;
begin
  result.sFilter:= sFilter;
  result.h:= Windows.FindFirstFileA( PChar(sFilter), vInfo.wfd );
  if result.h= INVALID_HANDLE_VALUE then begin
    result.iError:= Windows.GetLastError();
    case result.iError of
      ERROR_FILE_NOT_FOUND: ;  // The only error we don't need to display
    else  // Most likely ERROR_PATH_NOT_FOUND
      Windows.MessageBoxA
      ( Form1.Handle
      , PChar('Error initializing search "'+ result.sFilter
        + '": 0x'+ IntToHex( result.iError, 8 ))  // Get text message elsewhere
      , PChar('Error')
      , MB_ICONSTOP
      );
    end;

    result.iMatches:= 0;
    ZeroMemory( @vInfo, SizeOf( vInfo ) );  // Nothing to see here
  end else begin
    result.iError:= ERROR_SUCCESS;
    result.iMatches:= 1;
  end;
end;

function MyFindFile2nd
( var vHandle: TMyFindHandle
; out vInfo: TMyFindInfo
): Boolean;
begin
  result:= Windows.FindNextFileA( vHandle.h, vInfo.wfd );
  if not result then begin
    vHandle.iError:= Windows.GetLastError();
    case vHandle.iError of
      ERROR_SUCCESS,  // The only errors we don't need to display
      ERROR_NO_MORE_FILES: ;
    else
      Windows.MessageBoxA
      ( Form1.Handle
      , PChar('Error during search "'+ vHandle.sFilter  // Original filter from 1st call
        + '" after '+ IntToStr( vHandle.iMatches )+ ' elements occured: 0x'
        + IntToHex( vHandle.iError, 8 ))
      , PChar('Error')
      , MB_ICONSTOP
      );
    end;
    Windows.ZeroMemory( @vInfo, SizeOf( vInfo ) );  // Nothing to see here

    if not Windows.FindClose( vHandle.h ) then begin  // Release resource
      vHandle.iError:= Windows.GetLastError();
      case vHandle.iError of
        ERROR_SUCCESS: ;
      else  // Yes, this can fail, too
        Windows.MessageBoxA
        ( Form1.Handle
        , PChar('Error finalizing search "'+ vHandle.sFilter  // Original filter from 1st call
          + '" after '+ IntToStr( vHandle.iMatches )+ ' elements occured: 0x'
          + IntToHex( vHandle.iError, 8 ))
        , PChar('Error')
        , MB_ICONSTOP
        );
      end;
    end;
  end else Inc( vHandle.iMatches );  // One more match
end;


// Now the example on how to use it
procedure TForm1.Button1Click(Sender: TObject);
var
  vHandle: TMyFindHandle;
  vInfo: TMyFindInfo;
begin
  vHandle:= MyFindFile1st( 'C:\Windows\*.exe', vInfo );
  while vHandle.iError= ERROR_SUCCESS do begin
    Memo1.Lines.Add( vInfo.wfd.cFileName );
    MyFindFile2nd( vHandle, vInfo );  // Don't even need the Boolean result here
  end;
  Memo1.Lines.Add( '= '+ IntToStr( vHandle.iMatches )+ ' FS objects' );  // Not only files
end;

At no time there is a need to re-request a detail by handle, because you can keep that detail right with the handle that you need to take care of anyway. Just put both together into a record and pass that to your own functions.

My code is for demonstration purposes (although I think it's a rather trivial overall case). I discourage from displaying dialog windows right in those functions, but instead react upon what vHandle.iError contains where I called those functions.