file counting

Peter Luijer wrote:
Like others already said: you still have to count all files manually
(with a ).
>
If you want I got a simple threaded fileparser-code, by assigning an
Find-event you can simply increase a count-integer variable:
>
[code]
Unit FileFinder;
>
Interface
>
Uses
Classes, SysUtils;
>
Type
TFinderFindEvent = Procedure(FileName : String; Var Abort : Boolean)
;

Avoid unnecessary string reference counting. Pass strings as const.

TFileFinder = class(TThread)
Private
fAbort : Boolean;
fCur : String;
fPath : String;
fExt : String;
fRec : Boolean;
Find : TFinderFindEvent;
Protected
Procedure Execute; ;
Procedure UpdateFind;
Public
Constructor Create(AFilePath : String;
AExtension : String;
ARecursive : Boolean;
AFind : TFinderFindEvent);
Procedure Abort;

Since this method is public, and it never gets called from code in this
unit, it must be something you expect to be called by other code in other
threads. Keep this in mind for a later comment

End;
>
Implementation
>
Procedure TFileFinder.Execute;
>
Procedure ProcessRec(Rec : TSearchRec);

Avoid unnecessary copying of records on the stack. Pass records as const.

, since this is a local procedure anyway, don't pass it at all. Just
declare R before ProcessRec, and then use R wherever you now use Rec.
(Doing that also avoids the confusing situation of Rec and fRec having
similar names but completely different meanings within the same
statements.)

Begin
fCur := fPath + Rec.Name;
If (Not fAbort) Then
If (Rec.Attr And faDirectory 0) And
(Rec.Name <'.') And
(Rec.Name <'') And
(fRec) Then
TFileFinder.Create(fCur, fExt, fRec, Find)

With this, you create a new thread for every directory on the system. That
could mean hundreds of threads running at the same time!

If you want to allow having multiple threads traversing the file system at
once, I suggest you use a thread pool to limit the number that are
contending for the same resource at the same time.

Else
If (fExt = '')
(LowerCase(ExtractFileExt(Rec.Name)) = fExt) Then
Synchronize(UpdateFind);

Note that the Find event will not receive paths that end with directory
names. Instead, a directory path will end with a backslash and a dot or
dot-dot. Valid, but probably not what's expected.

End;
>
Var
R : TSearchRec;
Begin
fAbort := False;
fCur := '';
fPath := IncludeTrailingPathDelimiter(fPath);
If (FindFirst(fPath + '', faAnyFile, R) = 0) Then
Try
ProcessRec(R);
While (Not fAbort) And
(FindNext(R) = 0) Do
ProcessRec(R);

I notice that you don't check the Terminated property in this loop. That
property seems to serve the same purpose as your FAbort field.

Finally
FindClose(R);
End;
End;
>
Constructor TFileFinder.Create(AFilePath : String;
AExtension : String;
ARecursive : Boolean;
AFind : TFinderFindEvent);
Begin
Inherited Create(True);
FTerminate := True;

You set FTerminate to True, meaning that the object could get freed
at any time. The code that instantiated this thread class won't get any
notification when the thread terminates, but you've still provided a
public method to call on this thread. This is a dangling pointer waiting
to happen.

If Assigned(AFind) Then
Begin
fPath := AFilePath;
fExt := LowerCase(AExtension);
fRec := ARecursive;
Find := AFind;
Resume;
End
Else
Free;

If having a callback method is a precondition for creating the thread,
then the proper way to enforce that is by raising an exception. Do not
make the object silently free itself. That could lead to an access
violation (since the AfterConstruction method will still get called on the
now-stale object reference, and TThread's AfterConstruction method
actually does non-trival work!). Either call Assert(Assigned(AFind)) or
raise your own exception.

Even if the call to AfterConstruction doesn't crash, you run the risk of
returning a stale object reference from the constructor. The caller is
given a non-null reference to an object that already doesn't exist. That
typically *never* happens. It's ingrained in developers' minds that if a
constructor returns, then the result is a valid object reference -- a
reference that should be safe to call Abort on, in this case. Don't
violate that rule.

End;
>
Procedure TFileFinder.UpdateFind;
Begin
If Assigned(Find) Then
Find(fCur, fAbort)

Since a non-null Find event is a precondition for creating the object,
you don't need to check it here.

Else
fAbort := True;
End;
>
Procedure TFileFinder.Abort;
Begin
fAbort := True;

If someone calls Abort on this thread, isn't the expectation that there
will be no more (or at most one more) Find event? So what do you do
about the possibly hundreds of other enumeration threads that this thread
has spawned? Shouldn't they be aborted, too?

End;

How is the program supposed to know when file enumeration in this class
has finished?

--
Rob