open the file and have a do until loop that stops once you get to the end of the file, and in the middle of the loop check each data line to see if it has characters or not
If checking for a zero-byte file was as simple as opening the file, we could:
[tt]
ff = FREEFILE
OPEN "TEST.TXT" FOR BINARY AS #ff
PRINT "TEST.TXT IS" ; LOF(ff) ; " BYTES LONG."
CLOSE #ff
[/tt] One of the problems with opening a file to get it's size is that the act of opening creates a zero-byte file, if one didn't already exist. Unlike Visual Basic, QB doesn't provide a handy way to get the length of a file... but it's a fairly simple matter to get that information (and more) with the DOS interrupts:
[tt]
DEFINT A-Z
TYPE RegTypeX
AX AS INTEGER
BX AS INTEGER
CX AS INTEGER
DX AS INTEGER
bp AS INTEGER
Si AS INTEGER
DI AS INTEGER
Flags AS INTEGER
DS AS INTEGER
ES AS INTEGER
END TYPE
DIM inRegs AS RegTypeX, Outregs AS RegTypeX
'Let's look for a file in the current directory called "TEST.TXT"
SearchFile$ = "TEST.TXT" + CHR$(0)
'Get the address of the Disk Transfer Area
inRegs.AX = &H2F00
CALL INTERRUPTX(&H21, inRegs, Outregs)
SegDTA = Outregs.ES
OffDTA = Outregs.BX
'Find first matching file. (Find a match for "TEST.TXT"
inRegs.DS = VARSEG(SearchFile$)
inRegs.DX = SADD(SearchFile$)
inRegs.CX = &HFF
inRegs.AX = &H4E00
CALL INTERRUPTX(&H21, inRegs, Outregs)
IF Outregs.Flags AND 1 THEN
PRINT SearchFile$; " was not found."
'If the file doesn't exist, quit.
SYSTEM
END IF
'Peek into the DTA to get the file size
DEF SEG = SegDTA
S$ = ""
FOR Re = OffDTA + 26 TO OffDTA + 29
S$ = S$ + CHR$(PEEK(Re))
NEXT
MyFileSize& = CVL(S$)
IF MyFileSize& = 0 THEN
PRINT "File is zero bytes."
ELSE
PRINT "File size: "; MyFileSize&; " bytes"
END IF
DEF SEG
[/tt]
The question was: "HOW DO I TELL IF A TEXT FILE IS EMPTY".
My first question would be, "does the file exist?" If the file exists it would be a simple matter of opening it and checking its length. If the file doesn't exist, opening it would provide a very poor test. Opening it would create a file where none existed before and it would prove to be empty in every instance.
This is a slightly reckless approach. Let's say you have the names of fifty files and you want see how many of them are empty. (For example, let's say that there are thirty files in a folder: twenty of them are a kilobyte in length and ten of them are zero bytes in length.) Should you open all fifty of them and check their lengths with LOF? The proposed method would not tell us that ten of the files are empty. We would be led to believe that thirty files are empty.
How would you clean up after this? Delete thirty empty files? If you did so, the empty file count would be zero, not ten. There goes any hope of an accurate count.
I hope you see where I'm going with this. The question "is a file empty?" isn't an exercise in existentialism. It's a question of effective programming.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.