quackquack69
02-27-2003, 04:33 PM
Hi! Just a question: I know how to read data from a file by reading each item, seperated by a comma, into variables.
e.g.: Input #1, var1, var2, var3
However, I want to read in a whole line at a time into a string variable, regardless of the ","s. how do I do that? Someone told me to use input$, but either I don't know how to use it or this is not the right code?
Please help!
thanks in advance
Simon
Squirm
02-27-2003, 04:35 PM
Line Input #filenumber, StringVariable
RickP
02-27-2003, 04:48 PM
The above will work, but try this:
Project->references->Microsoft Scripting Runtime
-------------------------------------------------------------
Dim FileSys as New FileSystemObject
Dim File as TextStream
Dim strInput as String
Set File = FileSys.OpenTextFile("filename")
strInput = File.ReadLine
--------------------------------------------------------------
I know it's more code, but you can do more things with the text files easier with FileSystemObject and TextStream. Hope this helps.
Squirm
02-27-2003, 04:52 PM
Yet another member recommends the FSO.
The FileSystemObject (FSO) was created primarily for use in scripting. There is nothing it can do which cannot be done with plain VB code, and it adds an extra (and of course unnecessary) dependancy to your project which may need to be packaged along with your program should you try to distribute it.
In short, you should avoid the use of the FSO in Visual basic applications.
For the lazy, ChiefRedBull has created an excellent FSO-substitute which can of course be compiled into your application. Find it here (http://www.visualbasicforum.com/showthread.php?s=&threadid=33238).
loquin
02-27-2003, 05:18 PM
Really, the only thing that fso has going for it is that you wouldn't have to change the code if you moved it over to a scripting environment.
vb native code is faster
vb native code is smaller
vb native code handles binary data easily
vb native code handles random access files
RickP
02-27-2003, 05:32 PM
It's an object oriented world guys. I find the overhead of this object a small price to pay for the ease of reading.
In short, you should avoid the use of the FSO in Visual basic applications.
I have to disagree. Where not living in a world where you have to be scared to use memory.
Squirm
02-27-2003, 05:39 PM
This has nothing to do with using memory.
Ease of reading is a poor excuse. Any code can be made more readable by chopping it into function calls. You could very simply write a class to mimic the FileSystemObject using nothing but plain VB file IO techniques. The result would be code which is just as easy to read. Take a look at ChiefRedBull's example at the link in my previous post. It does just that.
The problems with the FSO are as loquin mentioned above. Is the ease of readability worth that extra 1.5Mb on your installation package?
RickP
02-27-2003, 05:44 PM
I see your point. I use the FileScriptingObject because I'm not to worried about the size of the package, since all the apps I write are internal to the office.
loquin
02-28-2003, 10:32 AM
Whereas mine are also used internally, & I wouldn't care about the distribution size, but in some, I'm reading 50-100K TIF files & processing internal metadata from them. To attempt this in fso would be an exercise in futility. Even if fso could process binary files, the additional overhead (fso is apx. 50% as fast than vb native) would double the time requirements. The process already takes hours to complete.
Also, I just opened a 3+ mb text file, processed it line-by-line, and inserted 13K records (about 2/3 of the file) into an Oracle database.
By loading it as binary directly into a string, the load took apx. 1 second. Max.
If you're looking at large files, or large numbers of files, VB native code IS the way to go. IMO, the only advantage of fso is portability to a scripting app.
RickP
02-28-2003, 10:39 AM
Ok you win. I'll sharpen up on my VB native file I/O.