Prev: If you had to move from VB6...
Next: Modify app.config file
From: Saga on 24 Feb 2010 12:16
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


From: Armin Zingler on 24 Feb 2010 16:16
Saga schrieb:
>> 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.

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...)


--
Armin




From: Saga on 24 Feb 2010 16:32

"Armin Zingler" <az.nospam(a)freenet.de> wrote in message
news:ePtNCcZtKHA.4568(a)TK2MSFTNGP05.phx.gbl...
> Saga schrieb:
>>> The second is the worst solution.
>>>
>> Why?

> 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
>
> --
> Armin
>
>
>
>


 | 
Pages: 1
Prev: If you had to move from VB6...
Next: Modify app.config file