I have a loop that copies files from one dir to another;

Dim sNextFile As String
    sNextFile = Dir$(ppgdi.PublicProgramLocation & "*.*")

Do Until sNextFile = ""
  LogPrint "Copying '" & sNextFile & "'"
  If SyncFile(argumnets...)<> "" Then MsgBox "Error!"
  sNextFile = Dir$
Loop

But my 'SyncFile' function uses the DIR$ function too
which is clearing the DIR$ in my loop.  Is there a way to
have to instances of the DIR$ function so one does not
overwrite the other? -Kevin

<cut>

No.  Why does SynchFile use it?  If it's just to test for file existence
then there are better ways to do that (and this is the exact reason why you
NEVER use Dir$ to test for existence).  If SyncFile needs to loop then you
can use Dir$ in a loop to build an array or collection of filenames first
and then process that calling SynchFile for each entry.  You can also switch
to the FindFirstFile/FindNextFile/FindClose API calls which can be used to
run multiple simultaneous directory scans.

--
Reply to the group so all can participate
Personal replies to bob Chr$(95) butler Chr$(64) cox Chr$(46) net
VB.Net... just say "No"

No. Dir$() is non-reentrant.

No.

Remember, Dir is a global function.  It doesn't know the difference between
using it in one procedure from using it in another procedure.  Whatever you
use Dir for in one procedure is going to affect an "active Dir" in another
procedure.  Depending on what you're using Dir for in your SyncFile
function, there might be a better alternative to Dir. For example, you
should never use Dir to check for the existance of a file.....simply because
of this "problem" (the problem is actually with your code because this is
exactly how Dir is designed to work, so you can't say it's a bug or problem
with VB, per se).

A bit more advanced and complicated than Dir, but more efficient and
versatile, are the FindFirstFile, FindNextFile, and FindClose API functions.
You can use those "isolated" between different procedures.  IOW, using them
in one procedure has no effect whatsoever on using them in another
procedure.

Mike