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

[code]
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
[/code]

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.

[code]
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

[/code]
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.

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]
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)
[/code]

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]
fileOneContent = fileOneContent + vbNewLine + temp
[/code]

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

[code][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
[/code]

That should work, clean and simple.

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]
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
[/code]

Hope this helps.

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

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]
fileOneContent = fileOneContent + temp[/code]
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]fileOneContent = fileOneContent & temp & vbcrlf[/code]
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)

[quote author=kamakazie link=board=17;threadid=828;start=0#msg6520 date=1048807621]
Learning the FileSystemObject is more difficult than using the native vb functions, atleast from my perspective.
[/quote]

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

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.

[quote author=Grok link=board=17;threadid=828;start=0#msg6538 date=1048819842]
[quote author=kamakazie link=board=17;threadid=828;start=0#msg6520 date=1048807621]
Learning the FileSystemObject is more difficult than using the native vb functions, atleast from my perspective.
[/quote]

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

[/quote]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.

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.

[quote author=K link=board=17;threadid=828;start=0#msg6607 date=1048917675]
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.
[/quote]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.

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?

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.

[quote]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. [/quote]

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.

Hey I didn't mean to start a war.

I posted an optional way to do it from a professional perspective. Using FileSystemObject has several points of merit in the paid development world.

#1, as Skywing points out, advanced in the algorithm behind libraries will be automatically inherited by any code written that uses those libraries. In this case, so long as the GUID doesn't change for the interfaces of FSO, the code will automatically get better if they find a faster/better way to implement them.

#2, by using FSO, any programmer in the world familiar with FileSystemObject library can take once glance at the code snipped and easily maintain your code. so its a good idea to practice using libraries that other programmers around the globe are familiar with. maybe not for your bot, but for your skills.

nah you dont have to learn every method property and event in a library just to use a few functions from it. if kamakazie wants to do that, great for him. most programmers in the world find a library that has a few functions they need, and choose the library just for those. forget the rest.

we just compared two libraries at work that convert PDF to TIFF very quickly. we only needed 2 of the properties and 1 function call. each library had a hundred or more other procedures we could've studied, but we didnt care about them. one of the libs turned out to be 10x faster than the other, so we purchased it and used that 1 function.

Skywing touched on, barely, a counter-point. Using libraries isn't always the best thing to do when learning. It is educational to try to write your own functions that emulate library calls. Then when you're capable of doing it yourself, go ahead and use the library.

I could go on, but won't.