How to read this paricular file entire contents????

[Prity]

Hi

I have 1 small program, only 1 form on that form i have kept a command btn in that this below code i have written

Private Sub Command2_Click()
fj = FreeFile()
Open App.Path & "\bmpraw.txt" For Input As #1
While Not EOF(1)
    Line Input #1, readbmp
    readresult = readresult + readbmp
    k = k + 1'''Here i m capable of reading some 3 to 5 lines later i m 
'unable to read, its coming out and closing the file
Wend
Close #1
End Sub

Form this above code my program should read entire data, that is till end of file and data what ever is present in the file bmpraw.txt, in the exact way should get stored in variable readresult.

And my file size is 328kb, i dnt no how to attach it...

Thanks

[DataMiser]

I don;t see a problem with the code, assuming of course that it is a text file where each line ends with a CRLF.

Keep in mind however that line input reads up to a CRLF and drops the CRLF from the data you must add it back to get an exact copy of the file you are reading.

You can also use binary access and read the entire file in one shot which will work with any kind of file.

Dim InData As String
Open App.Path & "\bmpraw.txt" For Binary As #1
   InData = Space(LOF(1))
   Get #1, , InData
Close #1

MsgBox Len(InData)

[WoF]

No. You not "can also use", but you MUST use binary access, like DataMiser showed in his sample.
Like he said, Line Input is dropping characters which are taken for line end signals. You never get a complete read then.

[DataMiser]

Actually it depends on what you are doing with the file, If the file contains CRLF as in a standard text file then yes you can also use line input you just need to either use Print # when writing to a file or add & VbCRLF to the string read from the file. It will work just fine.

Now if the file has no CRLF you will have some serious issues with the line input method.

The thing is that line input expects every line to be terminated by a CRLF, it does drop these characters but we know what they are and can easily append them if needed no problem. However if the file is not broken into lines using CRLF the method will read until it either gets a CRLF or EOF if it get eof before the CRLF it will generate the input past end of file error.

One trick that while I would not use it will work is to append a crlf to the end of a file that has no CRLF in it and use line input to read the entire file which will drop the crlf you have added and give the original file content. This will nto work if there is even 1 CRLF located within the file however.

There is also an input method that will allow you to input a specified number of bytes and there is the RTB control which allows you to read a text file right into the textbox. It all depends on what the content of the file is and what you want to do with it once you have read it.

[dglienna]

Just load it into a RTB, with wordwrap, or just break up the lines between words

[DataMiser]

That is one way, which I had also mentioned but again it depends on what you want to do with the data once you have read it that will determine what the best course of action is.

[dglienna]

Two, actually.

You can then get the lines from the RTB

Option Explicit

Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" _
(ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As String) As Long

Private Const EM_GETLINE = &HC4
Private Const EM_LINELENGTH = &HC1


Private Function ColorWords(ByRef rtb As RichTextBox, _
                            ByRef sFindString As String, _
                            ByVal lColor As Long) As Integer
On Error GoTo ErrHandler
    Dim lFindLength         As Long
    Dim lFoundPos           As Long
    Dim lTempPos            As Long
    Dim iOptions            As Integer
    Dim iMatchCount         As Integer
    
    ' Set search options
    iOptions = rtfNoHighlight 'used by default here
    If Check1(0).Value = 1 Then iOptions = iOptions + rtfWholeWord
    If Check1(1).Value = 1 Then iOptions = iOptions + rtfMatchCase
    
    ' Save the string-length
    lFindLength = Len(sFindString)
    
    ' Search for a single match. Find method returns
    ' the position of the first character of the item,
    ' or -1 if no matches are found.
    lFoundPos = rtb.Find(sFindString, 0, , iOptions)
    
    ' Loop until all occurences are found
    Do Until lFoundPos < 0
        iMatchCount = iMatchCount + 1
        rtb.SelStart = lFoundPos
        rtb.SelLength = lFindLength
        rtb.SelColor = lColor
        lTempPos = lFoundPos + lFindLength
        lFoundPos = rtb.Find(sFindString, lTempPos, , iOptions)
    Loop
        
    ' Return the number of matches
    ColorWords = iMatchCount
    Exit Function
    
ErrHandler:
    MsgBox "Unexpected error number-" & _
        CStr(Err.Number) & _
        " occurred in " & Err.Source & _
        ":" & vbCrLf & vbCrLf & Err.Description
End Function

Private Sub Command1_Click()
   ColorWords RichTextBox1, txtSearch.Text, vbRed
End Sub


Private Sub RichTextBox1_Click()


    Dim strBuffer As String
    Dim lngLength As Long
    Dim intCurrentLine As Integer
    Dim lngLineNumber As Long
        With RichTextBox1
        intCurrentLine = .GetLineFromChar(.SelStart)
        'get line length
        lngLength = SendMessage(.hwnd, EM_LINELENGTH, intCurrentLine, 0)
        'resize buffer
        strBuffer = Space(lngLength)
        'get line text
        Call SendMessage(.hwnd, EM_GETLINE, intCurrentLine, ByVal strBuffer)
        
        lngLineNumber = .GetLineFromChar(.SelStart)
        MsgBox "You selected line number " & lngLineNumber + 1 & " which says " & strBuffer
    End With
End Sub

[DataMiser]

That's a lot of code to get lines. If we are talking about a standard text file would be much simplier to use the line input # method and has much less overhead.

[WoF]

Guys, Prity is not talking about text at all. Although the filename suggests to be of type text, it contains raw bitmap data, with no CrLf separated lines whatsoever. So the proper method to read it in is what DataMiser suggested first, using binary read with Get.

[DataMiser]

yes if it is a binary file containing an image then binary is the way to go, the txt extension as well as the line input# and no mention of input past end of file error lead me to believe it was a text file. If this is not the case then line input is no good.

btw aren't you also assuming that it is a binary file based on the filename?
If it had no CRLFs then the file would not read at all and would trigger an input past end of file error instead.

What we need here is for Prity to tell us what kind of file it is and then we can give accurate advise.

[WoF]

As I recall what Prity was doing recently (sending images via RS232) I'm rather confident that it is like I said. Also the filename "rawbmp" gives a clue.

But I have to state that line input will NOT produce an input past end of file at all.
Any single Cr chr$(13) or even a single Lf chr$(10) will be taken as end of line, as well as the actual end of file is. If the image data by chance contains bytes with the values 10 or 13, you get an end of line there. These characters are then dropped during input. Line length is quite randomly then, I'd guess, but no input past end of file will occur. The last line ends with the end of file. No problem if there is no cr/lf at the end.

[DataMiser]

Really, if what you say is true then this has been changed, I have saw the input past end many times in the past due to no ending crlf.

I tested and sure enough you are correct about the input past end. I wonder when this was changed. It would appear that several things have been corrected and/or improved in VB6 and it's service packs. Many things that I have steered clear of due to past issues seem to be working better now. hmm. I wonder what else has changed that I am unaware of?

[WoF]

I would promise to notify you, but the thing is, I'm also unaware of such improvements.
I never knew this has ever been a problem as long as I work with VB, and I started off with VB4, (but skipped VB5).
There are many things I have learned that are not working good in VB5 and in Controls 5.0, which I glagly never touched.

Reading text files which were produced by Notepad and had no CrLf at the end of the last line, though, never gave input past end of file to me. Maybe when you were using the standard Input statement it would try to read more than there is. Not Line Input.

[DataMiser]

I used BasicA GW-Basic, Quick Basic, VB-Dos, VB3 back in the day. It's been a while but I am pretty sure the problem existed in those. VB4 I barely touched and went right into VB5 which I used for years before moving to VB6. I have definitenly saw this issue in VB5 using line input #.

The first copy of vb6 I used had issues with the data grid [the first cell would be empty for no apparent reason] I had became comfortable with the DAO and the first project with ADO did not work so well due to this bug and resulted in my continued use of VB5 for some time before switching over.

Needless to say I have been careful enough when working with files over the last several years that I had not discovered the error no longer occurred, I guess I had been burned to many times in the past.

VB5 IMO was a good language much improved over VB4 but not as good as VB6. I worked with it everyday for 3-4 years.

[dglienna]

I remember it being a problem a long time ago. We'd open a text file, and one CrLf (or Chr$(0)) in the middle would hose the rest of the file