FILE() function anamoly ? 3

[ramani]

Hi,

As per the Manuals.. Use FILE( ) to find a file on disk. FILE( ) returns true (.T.) if the file can be found; otherwise FILE( ) returns false (.F.).

But I fould that it is not true. I included many reports in a project and compiled the executable. I have coded in such a way ... to find out, if some report files were physically put in the users computer, it will be identified by the FILE() function and use that. Otherwise, create a report file on the fly from some stored tables (special creation by me) and use them. The problem started because the report files were also included by me in the project(though it is not necessary in my case).

Problem.. FILE() function always returns .t., if the report file stays included in the project executable, but not available in DISK (because... my routines look for the file in DISK when .t. is returned by FILE(), but not available).

No problems.. if my special tables are used.. and if files kept on the user computer as specified .. but the files stands excluded from the project.

The QUESTION here is, the FILE() function not behaving as per the specification. Can some one point out.. if I am going wrong somewhere?

Interestingly.. LOCFILE() also did the same behaviour in my limited testing. LOCFILE() is supposed to open up a dialogue when file is not found. But the round about way is..
IF JUSTFNAME(LOCFILE(...myFile...)) == myFile ..
I am getting a similar response like FILE().. and guiding me wrongly.

Is there any other alternative to avoid this ?

Thanks and regards to members who may try out for me

Ramani
ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[isonlyme]

Ramani,

Is SET PATH established ?

Is SET COMPATIBLE OFF ? (otherwise drive and directories are ignored)

Do yoy include the filenames extention in your FILES() ?

wilfredo

 

[DSummZZZ]

As wilfredo eluded to, FILE() will return true if the file is located anywhere in the search path, not just the default. I've been frustrated by this before too. Also, if the file is included in the executable, it will find it there since it is effectively in the default directory. If you need to check for the file being in a specific location, you will have to use the full path name.
Dave S.

 

[ChrisRChamberlain]

ramani

Somewhat lengthy but reliable.

lnFileExist = ADIR(laTemp,[C:\myapp\test.txt])
IF lnFileExist = 1
[tab]WAIT WIND [File exists]
ELSE
[tab]WAIT WIND [File does not exist]
ENDI

FAQ184-2483 - the answer to getting answered.​

Chris

 

[wgcs]

File(fName) does return true if it finds fname included in the .EXE, so "on disk" is misleading in the documentation for the function.

If you need to check if a file Realy exists on disk, use ADIR, or may "exist()" routine (which also supports file skeletons):

* This routine tells if any files exist using a given skeleton
Function Exist
parameter Skeleton
private eDir, RetVal, oErr, Err
  RetVal = .F.          
  oErr   = On('Error')  
  err    = .F.          
  on error err=.T.      
  RetVal = ( adir( eDir, Skeleton ) > 0 )   
  on error &oErr        
  if Err                
    RetVal = .F.        
  endif                 
RETURN RetVal

 

[rgbean]

Ramani,
I've always used a GOTFILE() function, and in truth the following is the "best" I've come up with. Previous versions included Win API and FOPEN() routines. This works the way FILE() should work - not looking inside the current executable and actually using the explicit path info if provided!

*FUNCTION gotfile
PARAMETERS zcfilename
PRIVATE zcfilename
IF TYPE(&quot;zcfilename&quot <> &quot;C&quot;
RETURN .F.
ENDIF
DIMENSION laJunk[1] && so it's local
RETURN (ADIR(laJunk, zcfilename, &quot;ARS&quot > 0)

* Note: Conscious decision to not include Hidden files
* made, so it matched results of previous
* GOTFILE() AND FILE().

Rick

 

[ramani]

Hi,

Thanks for the response.

I used.. (my exact code)..
IF ADIR(laRpt,&quot;REPTS\&quot;+cRptFile+&quot;.FRX&quot;,&quot;ARS&quot > 0

instead of
IF FILE(&quot;REPTS\&quot;+cRptFile+&quot;.FRX&quot

Instead of beating the bush with FILE() function, I put the code to rest with the above.

Since, I expected FILE() to function as it should be, I never put my mind to alternative solution.

The RESULT KB is that FILE() function has got something which MS-VFP team did not intend that to be !. No answer for that :-(

Wilfredo and DsummZZZ thanks for the input.. but I was Ok with those. All others had very similar codes and provide them with my votes.

Thanks friends.. and that is it

ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com