FindFirst/FindNext problem

[BobKellock]

Back in February 2007 I posted a message on this board about not
finding all
files with FindFirst/FindNext when executing a real mode BP7 EXE under
XP2 SP2
which runs it via NTVDM.

As there was no response I wrote a fix for it, but, recently I had the
same
problem with another utility (having fogotten about the fix) and found
that it
is a known problem and is published at http://support.microsoft.com/kb/154791

Although Microsft's article imples that the problem is with both
FindFirst and
FindNext I think it's only FindNext that falls over and that it does
work OK
provided that there are no other DOS calls between FindFirst and
FindNext.

Microsoft's solution is to install another version of NTDVM but, even
if you
can find it, it's of no help to other users of the utility if they
haven't got
a suitable version of NTVDM installed.

The fix, that I wrote, (see below) appears to be completely reliable
but is very
slow when there are a large number of files that match the mask.

Do you have a better solution?

Bob

Function FindFirstOrNext(PathAndMask : String;
Att : Byte;
Var SR : SearchRec;
Var Num : LongInt) : Boolean;

Var
SR2 : SearchRec;
N : Word;
DE : Integer;

begin
N := 1;
FindFirst(PandM,Att,SR2);
DE := DosError;
While (DE = 0) AND (N < Num) do
begin
FindNext(SR2);
DE := DosError;
inc(N);
end;
if DE = 0 then
begin
FindFirstOrNext := True;
SR := SR2
end
else
begin
FindFirstOrNext := False;
FindFirst('*.*',AnyFile,SR2);
if DosError = 0 then; {Clears any spurious DOS error 18}
end;
end;

Typical loop

Var SR : SearchRec; SRnum : LongInt;

......
SRnum := 1;
While FindFirstOrNext(C:\Odds\Fred*.*,Archive,SRnum) do
begin
...
...
end;
...

[Jochen]

Post by BobKellock
Do you have a better solution?

better?

(btw.: modern systems have findclose or something like that to free
memory)

if u have to do it that way that u described it ...

why not store (part of) the results in a list or array?
but u have to kill it if u don't need it anymore.

more administration of course. but only a small array of e.g. 100
SearchRec + offset will increase speed in your case.

So the next 99-100 items u can read from list or array.
But there is no rule that with next start of findfirst u get same list
again.
Same problem u should have with your way mentioned too.

If u wanna use "snapshot" of the SearchRecs u have to do one and walk
through that snapshot and when using such a SR from the list make sure
it is still vaild (and then delete the structure afterwards) ;)

greets
jo

[BobKellock]

..............
if u have to do it that way that u described it ...

I think I have to as it's a real mode BP7 programme without
any facility for calling FindClose

.........
why not store (part of) the results in a list or array?
........

Thanks Jo

Thats an excellent suggestion. I tried it on a test directory where
there are 5000 files matching the mask and it speeded it up
dramatically.

Bob

[Dr J R Stockton]

In comp.lang.pascal.borland message <4935b482$0$31330$***@newsspool
4.arcor-online.net>, Tue, 2 Dec 2008 23:18:38, Jochen

Post by Jochen
(btw.: modern systems have findclose or something like that to free
memory)

This is a Pascal newsgroup, not a Delphi one. All Delphi newsgroups
have 'delphi' in their names. See mFAQ.

[Marco van de Voort]

Post by Dr J R Stockton

Post by Jochen
(btw.: modern systems have findclose or something like that to free
memory)

This is a Pascal newsgroup, not a Delphi one. All Delphi newsgroups
have 'delphi' in their names. See mFAQ.

Findclose is not exclusively delphi. Dos lfn (int 21h AX=71A1h) also
specifies findclose. IOW this goes for lfn usage with BP too.