better way to check if file exists?

[Stuart McLachlan]

They didn't heed post 2.

GetAttr ?

Yep, but Post #3 and FindFirstFile was probably a better solution than causing a runtime error
Plus they were both posted at almost the same time and post #3 gave a usable function rather than a cryptic reference

[Dale Yarker]

From PBWin 8.0x Help

GETATTR can also be used to verify the existence of a file or directory, taking advantage of the fact that ERR will be set if the file/directory does not exist. See the example below.

Still in 10's help.

From MSDN for FindFirstFileA function

If the function fails because no matching files can be found, the GetLastError function returns ERROR_FILE_NOT_FOUND.

Back to choice of PB or API

[Michael Mattias]

Posts 7 and 8.
"The problem with using DIR$(filespec) in an EXIST function is,it throws off DIR$ (without filespec) continuity in the rest of your app."
and
"Thats persactly why I needed this..."

This issue - which is real - has been addressed by PB with the CLOSE option added to the DIR$ function.

I very much recommend using 'DIR$ CLOSE' after any use of DIR$ in your programs. Otherwise file operations against the folder in which the DIR$() function was called may be impacted.

This is essentially a "FindClose ()" WinAPI call against the search handle returned by FindFirstFile().

MCM

[Stuart McLachlan]

This issue - which is real - has been addressed by PB with the CLOSE option added to the DIR$ function.

CLOSE does not address this issue in any way..

Using DIR$ CLOSE also "throws off DIR$ (without filespec) continuity" in EXACTLY the same way that the code in Post #6 will
( i.e. if called in the middle of a loop containing DIR$() or DIR$(NEXT).)

[Steve Hutchesson]

Dave Navarro pre 2000.

FUNCTION exist(fname$) as DWORD
  FUNCTION = Len( Dir$(fname$, 17) ) > 0
END FUNCTION

I can do it with the FindFirstFile method but Dave's old code works fine.

[Stuart McLachlan]

Dave Navarro pre 2000.

FUNCTION exist(fname$) as DWORD
FUNCTION = Len( Dir$(fname$, 17) ) > 0
END FUNCTION

I can do it with the FindFirstFile method but Dave's old code works fine.

Lance Edmonds pointed out that that function was actually in Common32.bas in Samples back then.( see Post#6)
But it can cause problems. That is what started this thread back in 2001. See Tom Hamlin's post #7 and the OP's post #8.
That's no doubt why later versions of Common32.bas were changed to

FUNCTION Exist(FileSpec AS STRING) EXPORT AS INTEGER

    LOCAL fd    AS WIN32_FIND_DATA
    LOCAL hFind AS DWORD

    IF LEN(FileSpec) THEN
        hFind = FindFirstFile(BYCOPY FileSpec, fd)
        IF hFind <> %INVALID_HANDLE_VALUE THEN
            FindClose hFind
            FUNCTION = %TRUE
        END IF
    END IF

END FUNCTION

It's still there in the current Samples, even though ISFILE() now makes it redundant.

[Michael Mattias]

Using DIR$ CLOSE also "throws off DIR$ (without filespec) continuity" in EXACTLY the same way that the code in Post #6 will
( i.e. if called in the middle of a loop containing DIR$() or DIR$(NEXT).)

Huh?

In my professional (even if retired) opinion, that kind of misuse of DIR$(NEXT) is, in a word, "silly." Ok, in a second word, "irresponsible" for any veteran programmer to make.

Did you also know disk file operations may fail if you call CLOSE in the middle of a loop with WRITE# and or LINE INPUT ?

How about using DIALOG SET TEXT following a DIALOG CLOSE?

The best way to look at DIR$() and DIR$ CLOSE is the same way you look at (file) OPEN and CLOSE, or DIALOG NEW / DIALOG END... PB statements always used as matched pairs. .. an "initiator" (DIR$(filespec)), DIALOG NEW), actions against the object just initiated (WRITE#, DIALOG SET COLOR), and a "terminator" action (CLOSE, DIALOG END)

MCM

[Stuart McLachlan]

Huh?
In my professional (even if retired) opinion, that kind of misuse of DIR$(NEXT) is, in a word, "silly." Ok, in a second word, "irresponsible" for any veteran programmer to make.

In my opinion (professional or otherwise) , you've completely lost the plot again. I suggest you read the previous posts in the thread for a change before making irrelevant comments. Specficially, read posts 6 - 8. and then rethink whether your coontention that DIR$() CLOSE addresses the issue WHICH YOU AGREED IS REAL!

I'll ignore the rest of your condescending, off topic comments.

[Stuart McLachlan]

In my professional (even if retired) opinion, that kind of misuse of DIR$(NEXT) is, in a word, "silly." Ok, in a second word, "irresponsible" for any veteran programmer to make.

wstrFIlename = DIR$("*.bas")
WHILE wstrFileName > ""
    IF NOT FileExists(wstrBackupLocation" & wstrFilename THEN
        FILECOPY strFilename, wstrBackupLocation" & wstrFilename
    END IF
    wstrFilename = DIR$(NEXT)
WEND
DIR$ CLOSE

In what way is this code "silly" or "irresponsible" or a mususe of DIR$(NEXT)
As long as it does not use DIR$ in the FileExists function it is perfectly reasonable (although now that we have ISFILE(), we don't need a separate FileExists function
If the function FileExists uses DIR$ (which is the whole point of this thread). it is an issue.
This is exactly the issue which you agreed is real and claimed was addresses with DIR$ CLOSE.
Please explain how DIR$ CLOSE addresses this issue (as you claim)

[Michael Mattias]

Please explain how DIR$ CLOSE addresses this issue (as you claim)

DIR$ CLOSE closes the search handle on the folder against which the DIR$ ("filespec") statement was issued. Until this search handle is closed, renames or deletes from that folder will fail, as will attempts to delete the the folder.

In what way is this code "silly" or "irresponsible" or a [misuse] of DIR$(NEXT)

I meant it was a misuse of DIR$ CLOSE, not a misuse of DIR$(NEXT). That's the way I read your post #24.

[Stuart McLachlan]

DIR$ CLOSE closes the search handle on the folder against which the DIR$ ("filespec") statement was issued. Until this search handle is closed, renames or deletes from that folder will fail, as will attempts to delete the the folder.

Really?
'

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN() AS LONG
    LOCAL wsFile AS WSTRING
    LOCAL strCOntent AS STRING
    LOCAL x,ff AS LONG
    'Build some test files
    strCOntent = "Something in the file"
    FOR x = 1 TO 10
        ff = FREEFILE
        OPEN "Test" & FORMAT$(x,"00") & ".dmo" FOR OUTPUT AS #ff
        PRINT #ff, strContent
        CLOSE #ff
    NEXT
   ? "check the contents of the folder, there should be 10 matching files there"
    ' iterate through the file
    wsFile = DIR$(EXE.PATH$ & "\Test*.dmo")
    WHILE wsFile > ""
        KILL wsFile           'delete from the folder while the DIR$() file handle is open
        wsFile = DIR$()
    WEND
    DIR$ CLOSE
    ? "check the contents of the folder!!! - Deleting the files worked while the DIR$() file handle was open
END FUNCTION
'

[Stuart McLachlan]

Del.

[Scott Turchin]

Wow, this debate is still going on? It was going on in 1998...

FindNextFile, I can post my function which has worked for 20 years if need be, but someone has a close version above.

[Stuart McLachlan]

Wow, this debate is still going on? It was going on in 1998...

FindNextFile, I can post my function which has worked for 20 years if need be, but someone has a close version above.

Don't bother, now we have ISFILE()