FindFirstFileEx liefert Error Falscher Parameter?

[DieDolly]

Ich habe gerade ein seltsames Phänomen. Eben habe ich eine Prozedur von FindFirst/FindNext auf FindFirstFileEx/FindNextFile umgeschrieben. Sie hat funktioniert!
Wenn ich diese Funktion jetzt aber aufrufe, gibt es den Fehler "Falscher Parameter". Die lief doch vorhin noch

Das hat mit FindFirst/FindNext immer funktioniert. Was ist intern an FindFirstFileEx anders? Darf man FindFirstFileEx nicht so schnell hintereinander aufrufen?
So rufe ich es auf, der Rest (Prüfen auf . und .. ist Standard. Aber es geht nicht über invalid handle value hinaus.

Delphi-Quellcode:

var
 lhFoundFile: THandle;
 lIndexInfoLevels: FINDEX_INFO_LEVELS;
 lfdStruct: TWin32FindData;
 lIndexSearchOps: TFindexSearchOps;
begin
 // ParentFolder: C:\Projekte\Logdateien\
 // Mask        : *.log

 lhFoundFile := THandle(Winapi.Windows.FindFirstFileEx(PWideChar(ParentFolder + Mask), lIndexInfoLevels, @lfdStruct, lIndexSearchOps, nil, 0));
 if (lhFoundFile <> INVALID_HANDLE_VALUE) then
  begin

Bei meinen ersten Tests habe ich immer Resultate bekommen. Mittlerweile bekomme ich gar nichts mehr zurück.

[TurboMagic]

Hallo,

je nach dem was du eigentlich vorhast gibt's evtl. auch einen Lösungsansatz in System.IOUtils?

Grüße
TurboMagic

[DieDolly]

Die dortigen Lösungen sind alle zu ineffizient.

Mittlerweile funktionierts wohl wieder, neuer Aufruf, keine leeren Variablen mehr

Delphi-Quellcode:

var
 lhFoundFile: THandle;
 lfdStruct: TWin32FindData;
 Index: Integer;
begin
 lhFoundFile := THandle(Winapi.Windows.FindFirstFileEx(PWideChar(ParentFolder + Mask), _FINDEX_INFO_LEVELS.FindExInfoBasic, @lfdStruct, _FINDEX_SEARCH_OPS.FindExSearchNameMatch, nil, 0));
 if (lhFoundFile <> INVALID_HANDLE_VALUE) then
  begin

[himitsu]

Wieso hattest du im ersten Post nicht alle nötigen Variablen initialisiert?
Wenn dir dann jemand um die Ohren wirft, dass es falsch ist, dann hat er bestimmt Recht.
Und ich möchte fast wetten, dass der Compiler das dir auch versucht hatte zu sagen, also warum höst du nicht auf ihn?

Das Result ist bereits THandle.

lhFoundFile := FindFirstFileEx(PChar(ParentFolder + Mask), FindExInfoBasic, @lfdStruct, FindExSearchNameMatch, nil, 0);
_FINDEX_SEARCH_OPS ist nicht unbedingt nötig, zumindestens nicht, wenn es nicht mit {$ScopedEnums ON} deklariert wurde.




Man mischt NIEMALS statische und compilerabhängige Deklarationen.

ParentFolder und Mask sind bestimmt String. (kein AnsiString oder WideString/UnicodeString)
FindFirstFileEx ist ebenso dynnamisch, gegenüber FindFirstFileExA und FindFirstFileExW.
PWideChar ist fest, ebenso wie PAnsiChar, aber gegenüber dem dynamischen PChar.

Rate mal, warum 2009 so viel Knallte, als Delphi plötzlich von ANSI zu Unicode wechselte.

String -> PChar -> TWin32FindData -> FindFirstFileEx
AnsiString -> PAnsiChar -> TWin32FindDataA -> FindFirstFileExA
WideString oder UnicodeString -> PWideChar -> TWin32FindDataW -> FindFirstFileExW

[DieDolly]

Da steht sehr viel, aber verstanden habe ich nicht was du meinst.
Soll das so sein?
lhFoundFile := FindFirstFileEx(PChar(ParentFolder + Mask), FindExInfoBasic, @lfdStruct, FindExSearchNameMatch, nil, 0);

[himitsu]

Delphi-Quellcode:

lIndexInfoLevels := FindExInfoBasic;
lIndexSearchOps := FindExSearchNameMatch;
lhFoundFile := FindFirstFileEx(PChar(ParentFolder + Mask), lIndexInfoLevels, @lfdStruct, lIndexSearchOps, nil, 0);

Dein Code aus Post #1:
Verboten sind Variablen nicht, aber man sollte ihnen auch etwas zuweisen.

Und genau das sollte der Compiler dir auch gesagt haben,

Zitat:

Code:

[dcc32 Warnung] Unit11.pas(35): W1036 Variable 'lIndexInfoLevels' ist möglicherweise nicht initialisiert worden
[dcc32 Warnung] Unit11.pas(35): W1036 Variable 'lIndexSearchOps' ist möglicherweise nicht initialisiert worden

denn es war auch der Grund, warum sich FindFirstFileEx bei dir ab und an beschwert hat, wenn da im Speicher nicht zufällig eine mal 0 oder 1 drin war.