How to get the no. of lines on a file?

hey!
somebody can help me on how to get the no. of lines on a file in vb6? tnx in advance... :eek:

You need to read the content of the file and split it up after each line break.

VB Code:

Public Function GetLineCount(ByVal sFileName As String) As Long
    Dim hFile As Integer
    Dim sLines() As String
    hFile = FreeFile
    Open sFileName For Binary Access Read As #hFile
        sLines = Split(Input(LOF(hFile), hFile), vbCrLf)
    Close #hFile
    'only check if the last line is blank
    If Len(sLines(UBound(sLines))) = 0 Then
        GetLineCount = UBound(sLines)
    Else
        GetLineCount = UBound(sLines) + 1
    End If
End Function

not plagiarism but a separate way of doing it :D

VB Code:

Public Function GetLineCount(ByVal sFileName As String) As Long
    Dim hFile As Integer
    Dim sLines As String
    GetLineCount=0
    hFile = FreeFile
    Open sFileName For Input As #hFile
    Do While Not EOF(hFile)
        Input #hFile, sLines
        If Len(sLines) > 0 Then
            GetLineCount = GetLineCount + 1 'lines are not counted if blank
        End If
    Loop
    Close #hFile
End Function

I personally think it's wrong to not count any of the empty lines in a text document. Since empty lines are often used to separate paragraphs from each other and in my humble opinion an empty line is still a line. In my example I didn't count the very last line if it was empty since the last line can end with a new line character and in that case shouldn't normally be counted. However empty lines inside the document should be counted.

Apart from that mebhas code will use up less memory when it runs compared to mine (the memory will however be released when the function returns) but it will also be much slower especially on a large file since it reads only one line at the time. So it all depends on how you want to handle it. Both versions will work.

My 2 cents.

VB Code:

Dim hFile As Long: hFile = FreeFile()
Dim buffer() As Byte
 
Open <filename> For Binary Access Read Lock Write As #hFile
ReDim buffer(LOF(hFile))
Get #hFile, , buffer
Close #hFile
 
Dim lineCount As Long, i As Long
Const DELIMITER = ChrW$(10)
 
For i = 0 To Ubound(buffer) Step 2
    lineCount = lineCount - (buffer(i) = DELIMITER)
Next i

Not sure if the Get -> buffer part will work since I need to reinstall VB.

LOL, pena that will give you a negative line count. Congrats to the light green gem :)

Cheers :)

And no, it won't, because if it finds a delimiter it will subtract True which is -1 ;)

Quote:

---

Originally Posted by Joacim Andersson

LOL, pena that will give you a negative line count. Congrats to the light green gem :)

---

Nope, I think that would work fine..
if buffer(i) = DELIMITER:
lineCount - (buffer(i) = DELIMITER) =
lineCount - (True) =
lineCount - (-1) = lineCount +1

if buffer(i) <> DELIMITER:
lineCount - (False) =
lineCount - 0 = lineCount

Adding lines when find delimiter :)

Quote:

---

Originally Posted by penagate

Cheers :)

And no, it won't, because if it finds a delimiter it will subtract True which is -1 ;)

---

That's correct, my bad :thumb:

tnx to all, actually i already got my own code... but tnx you add my knowledge...

noielen....

how did you do it?
can you post your code?

I couldn't resist, here's a shorter one.

VB Code:

Public Function GetLineCount(ByVal sFileName As String) As Long
    Dim hFF As Integer
    Dim sFile As String
    
    hFF = FreeFile
    Open sFileName For Binary As #hFF
        sFile = Input(LOF(1), #hFF)
    Close #hFF
    If Len(sFile) Then
        GetLineCount = (Len(sFile) - Len(Replace$(sFile, Chr$(13), vbNullString))) + 1
    End If
End Function

Replace is slow. Looping and counting is the simplest and therefore quickest operation :)

I don't understand why you use Step 2 in the loop in your example pena. If the file is a normal ASCII text file the vbLf (which is a constant you could have used just as well as declaring your own :)) could of course be at any position in the file.

ASCII yeah. I was thinking of Unicode.

Also, the delimiter should just be 10 instead of Chr(10) since we are comparing byte values.

VB Code:

Dim strdata As String
Open App.Path & "\filename.txt" For Input As #1
numlines = UBound(Split(Input(LOF(1), #1), vbCrLf)) + 1
Close #1

That's the same code I used above but without the test for the last empty line. Just because you combine function calls into one line doesn't execute them faster, it just makes it harder to read and understand.

Oops! Sorry :blush: , i should have read it more closely, it would have saved me alot of time trying to find out how input works.

Well, all suggestions above are valid ways for checking the number of lines in a text file (with the corrections already mentioned to get Pena's code to work correctly). Many of them is discussing the speed issue, in my opinion many developers go into this issue to deep when there is no reason to do so. The bottle neck when it comes to speed for this code is the disk access (reading the file). This is what takes some time and you shouldn't access the disk more then you need to, so in most cases it would be best to read the whole content of the file in one go. This is the case in both my code as well as the code pena showed (and the code Andrew used as well).

It is probably (most certain, depending on how long each line is) faster to use a loop in a byte array, like Pena did, then to call the Split function, as I did, however you must also consider the readability of the code. If you haven't written clearly comments that describes what you do it is a bit harder to understand what the loop is actually doing since you must first figure out what 10 in a byte actually represents. For me clear code that is easy to follow might be better to use then to earn a couple of milliseconds. Especially in code like this that probably wont be used so many times in the program, it might matter if you run it a million times but in that case we are back to the issue that it takes a long time to read a million files so if it takes one second longer or shorter normally doesn't really matter much for the user anyway. Normally in that case you would probably want to slow the code down even further by showing some sort of progress to the user so he/she doesn't think the program have stopped responding.

I'm not trying, with this comment, to rant down on any of the code examples or to claim that my suggestion is the best. I only wanted to put this in some perspective. The same goes with trying to squeeze the code down to as few lines as possible. It's nice when you can use a one liner to do something as long as that one liner is clear and easy to understand. But IMHO combining many function calls on one line just to save some typing is rarely the best approach. I remember a few years back when it was very popular amoung many C developers to write as much as possible on one line, to actually make the code cryptic was the goal. Which is just stupid, making code cryptic should never be the goal, since those that have access to the source code should be able to read and understand it.

Code:

---

m=((a>b)?(a>c)?a:c:(b>c)?b:c)

---

The above C code might run slightly faster then if you would break it up on a couple of lines, but even if you know C it will take you a while before you figure out what it does.

It's also interesting that a simple question as this has become such a long thread. :)

Code:

---

if (a > b) {
    if (a > c)
        m = a;
    else
        m = c;
} else {
    if (b > c)
        m = b;
    else
        m = c;
}

---

...there, I had to :D

But I agree you shouldn't make things unreadable just for the sake of it. Only if it is a time-critical operation, then you can try different cryptic ways of making it faster, as long as you comment it :)