Reading a text file with Input# 2

[TheKing]

I am bringing in multiple records from a Text box.

These records are just long strings of spaces and numbers and Letters.

So I dim my object that I put them in as string since I have both numbers and spaces.

Now my problem is for example the length of the record is in the first 4 characters like 0087 would mean that a record's length is 87 characters long.

Well in the text file it is 87 characters long but the problem is that the last 20 are spaces.
When I read in my record is doesn't bring in the spaces so I only get a Len of 67 and that throws up an error in my program.

Is there a different way or an optional value to use in the Input# statement that will make sure it goes to the end of the record?
I do not know for sure if I am going to have a crlf at the end of the record.
I just know that the file is written with the write statement and in the text file they are on seperate lines.

Hope I gave enough information T^he_Kiⁿg

 

[Hypetia]

Try Binary i/o instead of Sequential i/o.
With Binary i/o, you can specify and control how many characters do you read in your buffer when you attempt to read from a file.

 

[BlackburnKL]

Have you considered the FileSystemObject? It reads text files one line at a time (one of a couple of ways). I think it would work for what you have described. Here is some sample code:

Dim fsoStream As New FileSystemObject
Dim txtStream As TextStream
Dim strTextFromFile As String

Set txtStream = fsoStream.OpenTextFile("FileName&quot

Do While Not txtStream.AtEndOfStream
strTextFromFile = txtStream.ReadLine

'Do something with the record just read

Loop

Set txtStream = Nothing
Set fsoStream = Nothing

This code could be placed in a procedure (perhaps a click event for a menu or command button.

Check it out. Good luck! BlackburnKL

 

[TheKing]

oh I am sorry I just noticed that I wrote text box in my first post.

I ment to say text file. If that makes a difference.

sorry T^he_Kiⁿg

 

[BlackburnKL]

I figured that part out. Try my suggestion. BlackburnKL

 

[MichaelRed]

Regardless of the parseing details, reading a file in vb on an incremental basis is SLoooooooooooooooW. Try the following function, and you can get the entire string into "memory" as a single 'object'. From this perpective, you can readily inspect' the file content in any number of ways and attempt different soloutions to the parseing issue.

If -as a text file- each "record" is on a seperate line, the enumerated value vbNewLine used in conjunction with the function split can be used to readily and simplistically seperate the 'string' into individual elements of a string array, which may be parsed seperatly acording to their individual characteristics as necessary.

Public Function basGrabFile(FilIn As String) As String

    'Michael Red    3/3/2003
    'Sample Usage:  ? basGrabFile("C:\MsAccess\DrawArcsInVB.Txt")
    'Note the Arg [FilIn] is the FULLY QUALIFIED PATH of the Source _
     and the entire text is returned to the caller [prog | procedure]

    Dim MyFil As Integer

    Dim MyTxt As String
    Dim MyPrts() As String
    Dim MyPrtRec() As String

    'Just grab the Stuff
    MyFil = FreeFile

    Open FilIn For Binary As #MyFil

    MyTxt = String(LOF(MyFil), " ")
    Get #MyFil, 1, MyTxt

    Close #MyFil

    basGrabFile = MyTxt

End Function

MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[TheKing]

You all have great suggestions, I am working on it now, thanks T^he_Kiⁿg

 

[bridamol]

Hey try this.

Suppose s is a variable in which you are reading the record from file. Then do this.

s = s & space(20)

this will add spaces at end of your string. you can calculate the number of spaces to provide. Above code adds 20 spaces.

 

[THOMASNG]

In my opinion, VB5, is buggy. VB6 is much better at text-file manipulation. See if you can go to VB6 and VB.Net.

 

[TheKing]

Thomasng - I am using VB6, to tell you the truth I have never used VB5.
bridamol - I am checking the length to find out if the data is correct. It is one of my first checks. I can't allow the data to be used by the program if it doesn't have the right amount of LEN. I have to assume that who ever sent me that data did it wrong if they don't have the right LEN.

Thanks for the sugestion.
T^he_Kiⁿg

 

[TheKing]

Hey BlackburnKL what reference do you use for the FileSystemObject?

I don't have it loded into my project I found out.

T^he_Kiⁿg

 

[BlackburnKL]

I believe that it is Microsoft Scripting Runtime. If not, let me know and I will look further. BlackburnKL

 

[TheKing]

BlackburnKL - that worked great, every things comes in now I am soo happy. Thanks alot.

MichaelRed - Your code worded as well, the only think I thought might be a problem is that I don't know how much memory the machine might have and some of these txt files can get very large, so I just errored on the side of caution and read them in one at a time.

Thanks all for helping me on this one.
T^he_Kiⁿg

 

[MichaelRed]

Anmother advantage of the procedure I posted is that, in a reasonable, sense, the actual memory is NOT an issue. VB (like most Win based apps) will automatically have and use 'ye olde swappee filee' and (within some reason) it jsut does some spooling w/o user (or programmer) intervention. On a system w/ just 128 Meg of (real) memory, running several office apps, I have sucessfully used the posted procedure (or minor variants) to 'haul in' 50MByte text files. The point is to utilize the system to -in several ways- minimize your (programming) effort. Since the procedure is instantiated with just a single line of code, you do not need to repetively "read" and "parse". The single line does the entire "READ". similarly 'simplistic' procedures could reducee the single string to an array of substrings (re the SPLIT function noted previously) - again without any explicit effort on your part, except to use the single call to such a procedure. Your effort would then be reduced to the real unique issue of parseing each individual record.

From my perspective, that is a LARGE part of the attractiveness of 'object orientated' programming. I often (hopefully USUALLY) take some part of my projects' time budgetss to develop one of more routines which I may then just utilize with a few argumnents to achieve the common tasks, just like getting a text file and breaking it down to receords and fields with a minimum of custom programming. While the textstream object does go in that direction, routines like the one posted here often permit the 'grab - chop - grind' operation to be performed with essientially three lines of code, just calling the procedure with the arguments.

MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[TheKing]

Wow, I see what you are saying

thanks
T^he_Kiⁿg