FindFirst/FindNext/FindClose dilemma 1

[PedanticProgrammer]

I am using FindFirst/Next?Close to examine the contents of a folder. The code looks like this:

LocalPath += AnsiString("C:\\Progrram Files\\InDesign\\Plugins\\*.*");
Result = FindFirst(LocalPath, Attributes, TheFile);

...
Result = FindNext(TheFile);
...
FindClose(TheFile);

The first time through, this code works as expected. However, the next time in the same session that I go through this code, the call to FindFirst (with the exact same parameters) produces a return code of 3. I have two questions, really. The documentation describes the return value as a "Windows error code" but searching for "Windows error code" produces no further documentation. So what does a return code of 3 mean? And, does any one know why this code works correctly the first time but not during subsequent operations?

 

[2ffat]

Are you saying the error occurs on the FindNext? How are you looping through the files?



James P. Cottingham
-----------------------------------------
^{I'm number 1,229!
I'm number 1,229!}

 

[PedanticProgrammer]

Here's the code, cleaned up a bit to remove some unrelated lines:

   int            NumRecords,
                           a;

   TSearchRec        TheFile;
   int Attributes        = 0;
   int Result            = 0;
   AnsiString FileName;

   AnsiString LocalPath = CSPath;  //  From another dialog--this path is correct.
   LocalPath            += AnsiString("\\*.*");
   bool FirstLoop        =                true;


   while(1)
   {
      if(FirstLoop)
      {
         Result = FindFirst(LocalPath, Attributes, TheFile);
         FirstLoop = false;
      }
      else
         Result = FindNext(TheFile);

      if(Result != 0)
         break;    //The second time through this break is executed.  Result == 3.

      FileName = TheFiles.ff_name;

      if(TheFile.Attr & faDirectory > 0 ||
         TheFile.Attr & faHidden    > 0 ||
         TheFile.Attr & faSysFile   > 0 ||
         TheFile.Attr & faVolumeID  > 0   )
         continue;

...  bunch of code deleted...
   }

The code I deleted from this example was commented out during a trial run and the problem still occurred, so I am convinced that it was not the source of the unexpected behavior.

 

[2ffat]

Hmmm...a bit complicated. Look at thread101-49144 and thread101-989298. Somewhere I have a listing of a recursive function that works very well. If you want that, let me know and I'll post it.





James P. Cottingham
-----------------------------------------
^{I'm number 1,229!
I'm number 1,229!}

 

[PedanticProgrammer]

I have solved the problem. it was indeed intervening code that caused it; but code that was outside of this module. It changed a path from something like C:\abc\def\ghi\jkl to C:\abc\defghi\jkl, a subtle change and hard to detect unless one has his nose rubbed in it. That change, of course, caused the FindFirst call to fail because the new path did not exist.

 

[c567591]

Were you using a global (at least to those functions) variable?