Splitting file data by new line

[MailMan]

Hey, Im trying to split the data from a text file by vbnewline, and it's not splitting it. Here's my code...

Code Select Expand


Public Sub Load_File()
Dim fileOneContent As String, temp As String, splits() As String
   Select Case Len(frmMain.txtFileLocation.Text)
       Case 0
           Call MsgBox("No file defined!", vbOKOnly, "Error")
           Exit Sub
       Case Else
           Open frmMain.txtFileLocation.Text For Input As #1
           Do Until EOF(1)
               Line Input #1, temp
               fileOneContent = fileOneContent + temp
           Loop
           Close #1
   End Select
   
   splits = Split(fileOneContent, vbNewLine)
   
   For x = LBound(splits) To UBound(splits)
       With frmMain.lstWords
           .ListItems.Add , , splits(x)
       End With
   Next
End Sub


It only adds one item to the list view... and it's the full files text, in one line... so I'm assuming it's not splitting correctly.

[dxoigmn]

Code Select Expand


   Dim a_sFile() As String
   Dim nFreeFile As Integer

   nFreeFile = FreeFile

   Open "C:\test.txt" For Input As nFreeFile
       a_sFile = Split(Input(LOF(nFreeFile), nFreeFile), vbCrLf)
   Close nFreeFile


I think the above is a lot cleaner, but to fix yours, add vbNewLine to the end of "fileOneContent = fileOneContent + temp" - making it "fileOneContent = fileOneContent & temp & vbNewLine".   Notice how I replaced + with &, which there is no difference but better in most cases so as not to confuse with the addition operator.

[tA-Kane]

I'm not sure how VB reads data according to your end-of-line delimiter, but if it reads it the way I think it does, then it removes the delimiter from the data read... So, it would be like doing this

Code Select Expand


Dim Origional As String, Replaced, OrigionalArray() As String, ReplacedArray() As String

Origional = "line1"+vbNewLine +"line2"+vbNewLine+"line3"
Replaced = ReplaceAll(Origional,vbNewLine,"")
OrigionalArray = Split(Origional,vbNewLine)
ReplacedArray = Split(Replaced,vbNewLine)


If such is the case, then it reading it in without adding the delimiter (vbNewLine) to before the read will result in basically a replaceall().

So, to fix, try something like this code (since I don't know how to use the lines of code you used, I'll guess)

Code Select Expand


   fileOneContent = fileOneContent + vbNewLine + temp


Edit: Bah, Kamakazie beat me to the reply! Oh well, either code should work.

[Stealth]

Code Select Expand

[Code]
   Dim x() As String, i As Integer
   
   x() = Split(fileOneContent, Chr(13))
   
   For i = LBound(x) To UBound(x)
       x(i) = Replace(x(i), Chr(10), "")
       'eat many tacos! and do assorted other things.
   Next i


That should work, clean and simple.

[Grok]

As usual, everybody doing things the hard way.

Go to project references, scroll down to "Microsoft Scripting Runtime" and check the box.

The following code adds all lines from a file to a listbox.

Code Select Expand


   Dim fso As New Scripting.FileSystemObject
   Dim ts As Scripting.TextStream
   Dim strLine As String
   
   Set ts = fso.OpenTextFile("c:\temp\textfile.txt", ForReading)
   Do While ts.AtEndOfStream = False
       strLine = ts.ReadLine
       List1.AddItem strLine
   Loop


Hope this helps.

[dxoigmn]

Learning the FileSystemObject is more difficult than using the native vb functions, atleast from my perspective.

[Atom]

Yeah i kinda agree, i think the other way is a little quicker... and thats not what he was asking for either. Ive looked over your code, and your mistake is right here.

Code Select Expand


fileOneContent = fileOneContent + temp
Your loop takes the file and gives it to you line by line(kinda stupid) but when this happens it excludes the Line Breaks. So what you need to do is:

Code Select Expand

fileOneContent = fileOneContent & temp & vbcrlf
vbCrlf is the same as VbNewLine, but shorter to type. The "+" operator is really meant for numbers, and can sometimes give you trouble using it like that, so using "&" is better for strings.

I'd also like to tell you that i can tell your either new to programming or new to vb, but your code is very good, and you think logically, and i like it. (Assuming you didnt copy and paste that from somewhere)

[Grok]

Learning the FileSystemObject is more difficult than using the native vb functions, atleast from my perspective.

!!!   FSO is intuitive and simple.  It is probably what we might write ourselves as a file object model.

[MailMan]

Yeah I wrote that myself. Appending the vbCrLf fixed it. I also changed the +'s to &'s. I'm pretty new to VB; sort of got bored one day and started messing around with it.

Thanks a lot for the help.

[Skywing]

Learning the FileSystemObject is more difficult than using the native vb functions, atleast from my perspective.

!!!   FSO is intuitive and simple.  It is probably what we might write ourselves as a file object model.

This brings up an important point: Libraries are there to be used, not avoided!  When I first started programming in "C++" (I use the term loosely, as STL is really an integral part), I pretty much avoided STL of all kinds, but in time I realized how much I was reinventing the wheel when readymade implementations could do better.

Believe me, using libraries is not "cheating"; it's the way to get stuff done in a timely manner.  You don't always have the luxury of being able to write your own code to do everything, and many libraries aren't the inefficient, bloated things some people make them out to be.

[K]

on the flip side of the coin, using the File System Object can often get your program flagged as a potential virus by programs such as Norton.

[Skywing]

on the flip side of the coin, using the File System Object can often get your program flagged as a potential virus by programs such as Norton.

Then those programs are seriously flawed.  "Obviously, anything which does I/O is a virus!"... a little broad, do you think?

If you want to be paranoid enough, any program is a potential virus - and if one method is something that's sure to set off alarms with a particular antivirus program, you can bet that it's one thing the virus authors will avoid, not use.

[dxoigmn]

Skywing, I understand what you're saying but in this instance I don't think it is necessary to use the MS Scripting library.  If MailMan understands the file operation functions in VB, then there is no reason to introduce him to a whole new library.  When I'm introduced to something new (e.g. a new library), I don't want to know the 1-2 functions I'll need from that particular library, I want to know how the whole thing works.  For new programmers as he stated he was, it's much easier from my experience to work with what they know instead of introducing them to potentially difficult topics.  To throw out a question, I'd love to know if MailMan actually looked into the FSO/TextStream objects and their respective properties/functions?  And/Or did you take the time to understand the Scripting library that FSO/TS are a part of?

[Yoni]

The reason anti-virus programs flag everything that uses the MS Scripting library as a potential virus is that this library is very often used in VBScript worms (i.e. the I Love You worm, etc.).
They block this library on a low level, so they can't easily differentiate between whether the caller is VBScript through Outlook Express, an independent program through the VB VM, or even a C++ program such as iexplore.exe (could be others, but it most commonly occurs with iexplore.exe).

In this specific example, there is not much difference between using FSO or not using FSO (though that Chr(10) is ewwy... Use vbLf or something) because the code is so simple. But the principle is you should use FSO, or whatever library is already available, if it makes the work much simpler.

[K]

In this specific example, there is not much difference between using FSO or not using FSO (though that Chr(10) is ewwy... Use vbLf or something) because the code is so simple. But the principle is you should use FSO, or whatever library is already available, if it makes the work much simpler.

Exactly. I'm not saying you should reinvent the wheel, but in this situation, there really isn't a need for the FSO. I'm not sure you can say always or never  use already available libraries. Just like with the rest of life, you have to weigh the pros/cons. The code may be simpler, but how much simpler? And is a small reduction in LOC worth the external dependencies you gain?

Just my two cents. Take or leave as you like.