Luis Rivera wrote:
- a is a file, not a string (Mask)
mydir is a string (the name of the directory to search in)
He talked about "a", not "mydir".
Oops! Right! Sorry! (I think I mistook the 1) as a reference to the first parameter)
I see. Perhaps another reason not to call parameters "a". ;-)
- reset has for parameter a file, not a string.
So it expects the string containing the filename...
... and the file, so it does not match TStringProc (even if Reset was a regular procedure, which it isn't for several reasons, so it can't be used as a procedural parameter anyway).
Well, besides the fact that I was still mistaking the filename with the file itself, I think this "irregularity" of Reset explains a lot already!
Not really. Even if it was regular, it wouldn't match as it takes two parameters.
So, correct me if I'm wrong, but valid procedures for this parameter would be deleting, copying, and stuff like that, a bit like DirAction, right?
These would be typical examples (for DirAction it might be things like MkDir or RmDir).
But the point here is not what the procedure does, but what parameters it takes. Procedural parameters must match exactly, and since the unit declares:
type TStringProc = procedure (const s: String);
your procedure header must look exactly like this:
procedure MyFileAction (const s: String);
If you initialize the variable with an empty string, you can check this way if the file was not found. Checking for IOResult is not a valid check for file not found -- if there is no file, FindFiles will simply not call FileAction, but not set an error code.
I see. So perhaps it was always a bad idea to try to use it to define a function returning boolean.
You do this (returning the value of "global-string <> ''" in the approach I described. Or you can just return the string (with empty meaning not found).
Frank