On 24 May 2010 18:55, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
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)
- 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! I guess my whole approach is doomed because of this.
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?
Please read more carefully what he wrote (see above), otherwise people here might not be willing to help you in the future:
You might want to declare a FileAction procedure
(which obviously means a procedure to be used for the FileAction parameter)
You did not do this, you still try to pass "Reset" here.
with a string parameter (nameoffile):
You did not do this either. You did not declare a procedure at all (and the only function you declare does not have a string parameter, but a file parameter, and is not for "FileAction" anyway).
You're right, I hadn't define this FileAction yet. I was kind of thinking aloud (or in writing, so to speak).
probably you would include in it the assign which is before findfiles in your program and the reset
"In it" means in the FileAction procedure. You try to do the "Assign" before calling FindFiles. How should this work? You cannot assign the filename before you have found it. (What you'd do is to assign the filename as typed by the user, but if the file is in a subdirectory, you don't get the directory, because you haven't searched it yet.)
Right. I already had the uneasy feeling of short-circuiting myself, and indeed I was doing so. Thanks.
Notice that if there are multiple files found, you will have an error because you then try to reopen a file (a) which has not been closed: findfiles apply FileAction on all files which match Mask.
Maybe I can get around that problem defining the FileAction procedure in such a way that wildcards are forbidden...
You still could have several files with the same name in different directories.
If you only care for any file found, I'd suggest to write a FileAction procedure that stores the file name in a (global) string variable. (If multiple files are found, the last one will be stored eventually.) Then after FindFiles returns (not in the FileAction procedure), assign the file to the name in the variable.
Got it! Thanks!
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.
In fact, GPC allows "nil" for procedural parameters (if the called routine expects it, which FindFiles explicitly does, as described in its comment).
OK. That explains a lot...
Well, I guess I'll have to cool down, get back to the blackboard, and rethink my whole strategy.
Thanks for all the feedback!