FiveTech Support Forums

FiveWin / Harbour / xBase community
Board index FiveWin for Harbour/xHarbour Function FILE(...)
Posts: 114
Joined: Tue Feb 14, 2006 08:13 AM
Function FILE(...)
Posted: Mon Jul 10, 2006 11:21 PM
Hi all,
Can someone verify if this is correct ???

   if file("CON.BMP")
      ? 'File exists'
   else
      ? 'File does not exist'
   endif

Why do I write this... because it returns .T. without
the file "CON.BMP" to exist !!!

FSize("CON.BMP"), returns zero (0) thank God !

I would like to know if anyone can confirm the problem (bug?)

Regards to all
Evans
Posts: 711
Joined: Thu Oct 06, 2005 09:57 PM
Function FILE(...)
Posted: Tue Jul 11, 2006 05:14 AM

From xHarbour Help:

"This function return a logical true (.T.) if the given filename <cFileSpec> exist.

Dos skeletons symbols may be used in the filename in <cFileSpec>, as may the drive and/or path name. If a path is not explicity specified, FILE() will look for the file in the SET DEFAULT path, then in each SET PATH path, until the file is found or there are no more paths to search. The DOS PATH is never searched and the current drive/directory is only searched if SET DEFAULT is blank. "

Try with full path: IF FILE ("C:\FIVEWIN\CON.BMP") ...

Un saludo



Manuel
Posts: 663
Joined: Mon Dec 05, 2005 11:22 PM
Function FILE(...)
Posted: Tue Jul 11, 2006 01:55 PM

This seems to be a xHarbour bug. I am guessing that it considers "CON" the console like other devices. For example lpt1, lpt2, con.

I don't know if Harbour does the same thing.

Posts: 140
Joined: Sat Oct 08, 2005 05:16 PM
Function FILE(...)
Posted: Tue Jul 11, 2006 03:41 PM

Evans:

I tried with other apps, like x32 (something like xTree) to rename
a x.bmp to "con.bmp" but seems that "con" is a reserved word.
With other app like IconWorkshop "save as.." -> "Con.bmp"
did not work because it said that it´s a reserverd word too.

Try with other name, here work fine with other name.

Sorry for my English

Regards

Ruben Fernandez

Rubén D. Fernández

Maldonado-Uruguay
Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Re: Function FILE(...)
Posted: Tue Jul 11, 2006 04:50 PM
E. Bartzokas wrote:Hi all,
Can someone verify if this is correct ???

   if file("CON.BMP")
      ? 'File exists'
   else
      ? 'File does not exist'
   endif

Why do I write this... because it returns .T. without
the file "CON.BMP" to exist !!!

FSize("CON.BMP"), returns zero (0) thank God !

I would like to know if anyone can confirm the problem (bug?)

Regards to all
Evans


It is not a bug. Try

notepad con.bmp


EMG
Posts: 114
Joined: Tue Feb 14, 2006 08:13 AM
Re: Function FILE(...)
Posted: Tue Jul 11, 2006 05:21 PM

Thank You All !

In the 16 bit environment, this function worked just fine.
It seems that one way or another it does not work now,
at least in the 32-bit environment, but luckily enough we
managed to spot this error (very hard to find though),
and had added .AND. FSIZE("CON.BMP") # 0.

This works for now, at least to the point where we want
it to work, but it ain't correct.

I'm strugling today, to make FT_PROPER() to work, by
adding NANFOR.LIB in my .XBP file, but I get an error
(GPF) and program crashes.
Anyone has any idea?
Using XHB (xBuild Wizard Version 4.01 Jan 24 2006
and FWH Feb 2006 relase.

Thanks for any help ... (need to convert string to
proper case eg. "evans" to "Evans")

Posts: 663
Joined: Mon Dec 05, 2005 11:22 PM
Function FILE(...)
Posted: Tue Jul 11, 2006 08:01 PM

I use the latest xHarbour Builder and nanfor. Ft_proper() does not GPF for me.

Does the directory() function find 'con.bmp' ?

Posts: 114
Joined: Tue Feb 14, 2006 08:13 AM
Function FILE(...)
Posted: Tue Jul 11, 2006 08:21 PM
Gale FORd wrote:I use the latest xHarbour Builder and nanfor. Ft_proper() does not GPF for me.

Does the directory() function find 'con.bmp' ?


Thanks for the reply. My FT_PROPER() does not work, but have invented a work-around in pure clipper (slower but reliable).

Directory("con.bmp") returns:

Length: 1
Name: "con"
Size: "0"
Date: "01/01/01"
Time: "03:00:00" // !!!!!!!
Attributes: "A"

File("con.bmp") returns .T. (still)

FSize("con.bmp") returns Zero

Now go figure all this... and imagine that we didn't have this
error in the 16-bit, otherwise, some of our clients would
have started screaming. At least three of our clients had
this problem recently (with con.bmp in 32-bit)

I live on a small mountain, 8 km away from civilization...
I think I'm going to start feeding seep and goats and
get the heck out of programming... it's so frustrating
to have functions working fine in 16-bit and now we
have to re-discover the wheel and evertyhing inside it...
one piece at a time, and full of surprises!

Thanks again...
Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Function FILE(...)
Posted: Wed Jul 12, 2006 10:10 AM

Please understand that this is a Windows file system issue not a FWH one. Just try to create a file called CON.BMP from Explorer and you will see. It is definitely a Windows file system reserved name.

EMG

Posts: 114
Joined: Tue Feb 14, 2006 08:13 AM
Function FILE(...)
Posted: Wed Jul 12, 2006 11:34 AM
EnricoMaria wrote:Please understand that this is a Windows file system issue not a FWH one. Just try to create a file called CON.BMP from Explorer and you will see. It is definitely a Windows file system reserved name.

EMG


I got you Enrico and thanks... I'll make the necessary changes
in the 32-bit program, so it will be avoided the next time.

What still puzzles me, is the fact that in the 16-bit environment,
the function file('con.bmp') returns .F. (correct)....

That's why I am now so sceptical. I thought that the behaviour of
any Fivewin 16/32 bit function would be identical, but apparently
I was wrong... and have to check each and everyone of them.

Regards and I apologize for my frustration.
Evans
Posts: 4840
Joined: Fri Nov 18, 2005 04:52 PM
Function FILE(...)
Posted: Wed Jul 12, 2006 04:05 PM

Evans,

My only consolation is that if it was easy, then anyone could do it, and we would all be out of work.

Unless you really like sheephearding ;-), programming is a nice job that you can do anywhere. We are lucky to have this job that didn't even exist 30 years ago.

And, you always have this nice group of people willing to help out. Priceless!

James

FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Posts: 114
Joined: Tue Feb 14, 2006 08:13 AM
Function FILE(...)
Posted: Wed Jul 12, 2006 06:53 PM

James,
You are absolutely right.
These are the reasons that I'm still around too,
regardless of the difficulties...
Chalenging is one thing that I wouldn't say no!

Thanks for your good words.

Posts: 160
Joined: Tue Oct 18, 2005 10:21 AM
Function FILE(...)
Posted: Sat Jul 15, 2006 09:02 PM
Evans,

I have just tested FILE("con.bmp") and FILE("C:\MYREPERT\CON.BMP")
with Clipper 5.3 with FW and Windows 98, and they return .T.
When i restart my pc with DOS without Windows, i have the same result.

For me, this is a Clipper error, or a undocumented convenience made
by someone...

I have writted a "correct" function, named FileExist().
This function do what FILE() could do, without reserved words...

#include "set.ch"
******************
FUNCTION FileExist(cFichier, lCacheSyst)
******************
* Auteur Badara Thiam
LOCAL nAttributs
LOCAL nCount := 1
LOCAL X
LOCAL cSepare := ""

IF "\" $ cFichier
ELSEIF !EMPTY( SET(_SET_DEFAULT) )
* Recherche dans le répertoire par défaut de clipper (SET DEFAULT TO)
  cFichier := TRIM(SET(_SET_DEFAULT)) + "\" + cFichier
ELSEIF !EMPTY( SET(_SET_PATH) )
* Recherche dans le(s) répertoire(s) du path de clipper (SET PATH TO)
  nCount := LEN( SET(_SET_PATH) ) - LEN( STRTRAN(SET(_SET_PATH),",","") ) + 1
  IF nCount = 1
    nCount := LEN( SET(_SET_PATH) ) - LEN( STRTRAN(SET(_SET_PATH),";","") ) + 1
    IF nCount = 1
      cFichier := TRIM(SET(_SET_PATH)) + "\" + cFichier
    ELSE
      cSepare := ";"
    ENDIF
  ELSE
    cSepare := ","
  ENDIF
ENDIF

FOR X := 1 TO nCount
  IF nCount = 1

    * With Windows apps
    nAttributs := GetFileAttributes(cFichier)

    * Or with Clipper DOS apps via Clipper Tools
    * nAttributs := FileAttr(cFichier)

  ELSE
    * With Windows apps
    nAttributs := GetFileAttributes( ALLTRIM( TOKEN(SET(_SET_PATH), cSepare, nCount) ) ;
    + "\" + cFichier)

    * Or with Clipper DOS apps via Clipper Tools
    * nAttributs := FileAttr( ALLTRIM( TOKEN(SET(_SET_PATH), cSepare, nCount) ) ;
    * + "\" + cFichier)
  
  ENDIF
  IF ( nAttributs >= 0 .AND. ( nAttributs % 32 ) < IIF(EMPTY(lCacheSyst), 2, 8) )
    RETURN .T.
  ENDIF
NEXT X
RETURN .F.

*******************
DLL32 FUNCTION GetFileAttributes( lpszSearchFile AS STRING ) AS DWORD ;
PASCAL FROM "GetFileAttributesA" LIB "KERNEL32.DLL"


Changed since last hour, add lCacheSyst to see all existing files if .T.
Badara Thiam
http://www.icim.fr
Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Function FILE(...)
Posted: Sat Jul 15, 2006 09:12 PM
Badara Thiam wrote:Evans,

I have just tested FILE("con.bmp") and FILE("C:\MYREPERT\CON.BMP")
with Clipper 5.3 with FW and Windows 98, and they return .T.
When i restart my pc with DOS without Windows, i have the same result.

For me, this is a Clipper error, or a undocumented convenience made
by someone...


Did you try to create CON.BMP from Explorer? If not, please do it and you will find that Windows doesn't allow to create a file with that name.

EMG
Posts: 160
Joined: Tue Oct 18, 2005 10:21 AM
Function FILE(...)
Posted: Sat Jul 15, 2006 09:41 PM

Enrico,

Yes, explorer cannot create CON.BMP,
but why Clipper File("CON.BMP") return .T. ??

This file doesn't exist. We not ask if the file
can be created but only if the file exist.

Badara Thiam
http://www.icim.fr