How do I process text file?

[Saga]

Hello all. I am using VB 2008 and need to process text fies. Looking
at MSDN Lib I see that two methods are used to read a text file:

Using StreamReader

Dim fileReader As System.IO.StreamReader

Using ReadAlltext

Dim fileReader As String
fileReader = My.Computer.FileSystem.ReadAllText("C:\test.txt")

Is one preferred obver the other? Any considerations I should look into?

Although the files that will be processed are text, I have seen a "bad"
non ASCII character get into them. I validate for this condition, but
given the fact that it is a non ASCII char, will either of the two methods
work or do I need to rethink the way that I open & read the files?

Thanks much! Saga

 

[Armin Zingler]

Hello all. I am using VB 2008 and need to process text fies. Looking
at MSDN Lib I see that two methods are used to read a text file:

Using StreamReader

Dim fileReader As System.IO.StreamReader

Using ReadAlltext

Dim fileReader As String
fileReader = My.Computer.FileSystem.ReadAllText("C:\test.txt")

Is one preferred obver the other? Any considerations I should look into?

Although the files that will be processed are text, I have seen a "bad"
non ASCII character get into them. I validate for this condition, but
given the fact that it is a non ASCII char, will either of the two methods
work or do I need to rethink the way that I open & read the files?

Well, the first is just a declaration. You'd need a FileStream to read from.

The second is the worst solution.

The best is directly calling IO.File.ReadAllText. It existed before and is
called by My.Crap. Therefore it's the straightest way.

You can optionally pass a System.Text.Encoding object. You must know
the encoding to correctly read the file.

 

[Saga]

Well, the first is just a declaration. You'd need a FileStream to read
from.

Not a problem, I just included the snippet to show the declaration.

The second is the worst solution.

Why? My question comes from the fact that I got both of these examples
(or partial example in case of the declaration) from MSDN Lib. In fact,
I just wrote some funtions that use the My.Computer.FileSystem object
to get a folder's contents and open a file. Using Google to search for
file handling methods seems to return lots of examples using this object.

The best is directly calling IO.File.ReadAllText. It existed before and is
called by My.Crap. Therefore it's the straightest way.

Cool, thanks for the tip. I will look into this.

You can optionally pass a System.Text.Encoding object. You must know
the encoding to correctly read the file.

In theory, the enconding is straight text, i.e. A-Z, a-z, 0-9 plus typical
symbols
(!@#$%^&*()_+=-, etc.). I say in theory because if the file is corrupt it
may
contain characters outside of this range. These files are created by another
application that uses plain text characters to create the file.

Thank you for your reply and assistance. Saga

 

[Armin Zingler]

Why? My question comes from the fact that I got both of these examples
(or partial example in case of the declaration) from MSDN Lib. In fact,
I just wrote some funtions that use the My.Computer.FileSystem object
to get a folder's contents and open a file. Using Google to search for
file handling methods seems to return lots of examples using this object.

What if it's not My computer? Maybe it's My Sister's computer?
My.Sisters.Computer doesn't work! Strange... ;-) IMO, the namespace name
was meant as a modern concession in the style of "My Space" etc., or as
something that can be read like a sentence, or that sounds cute enough
for us hobby programmers. My computer - how sweet!

Most parts of "My" have been introduced even as they've already been part
of the Framework before at a different (and IMO better) place, like System.IO.
It's redundant now in the MSVB library and a detour because most of the
functions just call the already existing functions. This way, VB is
unfortunatelly doing it's own thing again - a situation it luckily has moved
away from before.

In addition, my problem with My is that it's intransparent because a lot is
hidden behind the curtains and the IDE is often lying to me about what it
actually is what I want intellisense to tell me.

So if you don't want additional overhead, first try to use the "real" function.

Though, "My" may be useful with My.ressources, for example. (Though I wouldn't
have put it there, but...)

 

[Saga]

What if it's not My computer? Maybe it's My Sister's computer?
My.Sisters.Computer doesn't work! Strange... ;-) IMO, the namespace name
was meant as a modern concession in the style of "My Space" etc., or as
something that can be read like a sentence, or that sounds cute enough
for us hobby programmers. My computer - how sweet!

Okaaay...

Most parts of "My" have been introduced even as they've already been part
of the Framework before at a different (and IMO better) place, like
System.IO.
It's redundant now in the MSVB library and a detour because most of the
functions just call the already existing functions. This way, VB is
unfortunatelly doing it's own thing again - a situation it luckily has
moved
away from before.

In addition, my problem with My is that it's intransparent because a lot
is
hidden behind the curtains and the IDE is often lying to me about what it
actually is what I want intellisense to tell me.

So if you don't want additional overhead, first try to use the "real"
function.

Definitely don't!

Though, "My" may be useful with My.ressources, for example. (Though I
wouldn't
have put it there, but...)

Huh? Ok, that is another story. I guess I'll cross My.Resources when
I get to that.

Your input is appreciated! Saga