"Line Input" with Streamreader

  • Thread starter Thread starter Michaela Julia
  • Start date Start date
M

Michaela Julia

Hi,

I need to convert some very old files that have been once created using VB6.

Problem is, ReadLine() doesn't work like "Line Input" does.

Consider the following file:

1
"some info"
"more info"
"even more info"
"yet another
(multiline) info"
"yaddayadda"

The point of using quotes is that Line Input reads "yet another \r\n
(multiline) info" as one continous string whereas ReadLine() splits it
into 2 parts.
Is there any option to make .net StreamReader aware of enclosing quotes?

tia
 
The point of using quotes is that Line Input reads "yet another \r\n
(multiline) info" as one continous string whereas ReadLine() splits it
into 2 parts.
Click to expand...

Really? I never encountered this behavior in VB6, but then again I never
looked for it.
 
Hi,

I need to convert some very old files that have been once created using VB6.

Problem is, ReadLine() doesn't work like "Line Input" does.

Consider the following file:

1
"some info"
"more info"
"even more info"
"yet another
(multiline) info"
"yaddayadda"

The point of using quotes is that Line Input reads "yet another \r\n
(multiline) info" as one continous string whereas ReadLine() splits it
into 2 parts.
Is there any option to make .net StreamReader aware of enclosing quotes?

tia
Click to expand...

Nop that I know of. Now StreamReader.ReadLine() reads until he find
Environment.NewLine. Under this scenario you have two options:
1- Try to change what is returned by Environment.NewLine (not sure if
this can be done or even if it's the best way) and then you can use
StreamReader.ReadLine()
2- Simply create a new class than inherit from StreamReader and define
a new method similar to ReadLine
 
I need to convert some very old files that have been once created using VB6.

Problem is, ReadLine() doesn't work like "Line Input" does.

Consider the following file:

1
"some info"
"more info"
"even more info"
"yet another
(multiline) info"
"yaddayadda"

The point of using quotes is that Line Input reads "yet another \r\n
(multiline) info" as one continous string whereas ReadLine() splits it
into 2 parts.
Click to expand...

Are you sure? I'm fairly certain that "Line Input" just read lines as
is, and ignored any quotation marks and commas. Maybe you mean plain
"Input" (which does parse those things)?
Is there any option to make .net StreamReader aware of enclosing quotes?
Click to expand...

No. You need to write your own parsing code for that.

However, there is an easy workaround. If the input is governed by VB
rules, then just use VB.NET compatibility class library (which you can
do from C# just as well). For that you need the FileSystem class in
assembly Microsoft.VisualBasic. VB6 "Open" statement corresponds to
FileSystem.Open, and "Input" corresponds to FileSystem.Input (and
"Line Input" corresponds to FileSystem.LineInput, in case you still
need that). It's likely that implementations of those methods
implement all quirks that might exist in VB6 input/output formats
better than you would be able to do on your own.
 
Thanks for your .. er ... input :)

Yes, I wrote a little parser. It's a "one time only" conversion and
those multilines are the only "quirks" that come with it.
I will even let it run in debug mode to make sure everything is read ok
and dumped into a database.

Just had a nagging feeling that I was overlooking a simple but
inappropriately named method or parameter.

thx
 
Pavel,

The Microsoft.VisualBasic namespace has nothing to do with VB6, it is simply
a Net namespace like there is too Microsoft.Mshtml. This Net namespace add
some of the things which are a language part of VisualBasic but not standard
in in other Net program languages. There are not whatever plans to remove
this namespace ever from Net.

This VisualBasic namespace can be used within any Net program language like
any other namespace and are true Net without problems that they can become
forever not foreward compatible.

There is a VB6 compatible namespace Microsoft.VisualBasic.Compatibility.VB6

http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.compatibility.vb6.aspx

This awful thing covers things like the use of com objects which are not
included in Net . This one is not planed to stay forever in the frameworks.

One of the methods in the Microsoft.VisualBasic namespace is the
filesystem.lineinput
http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.filesystem.lineinput.aspx

I avoid using this in C# simply because of the fact that it makes my code
bad to understand for C# developers who don't understand VB.

(This lineinput statement I avoid everywhere, as I have found it forever an
awful piece of code, but that is of course just my preference)

Just to make this more clear because VB6 is not Net it is Com.

Cor


I need to convert some very old files that have been once created using
VB6.

Problem is, ReadLine() doesn't work like "Line Input" does.

Consider the following file:

1
"some info"
"more info"
"even more info"
"yet another
(multiline) info"
"yaddayadda"

The point of using quotes is that Line Input reads "yet another \r\n
(multiline) info" as one continous string whereas ReadLine() splits it
into 2 parts.
Click to expand...

Are you sure? I'm fairly certain that "Line Input" just read lines as
is, and ignored any quotation marks and commas. Maybe you mean plain
"Input" (which does parse those things)?
Is there any option to make .net StreamReader aware of enclosing quotes?
Click to expand...

No. You need to write your own parsing code for that.

However, there is an easy workaround. If the input is governed by VB
rules, then just use VB.NET compatibility class library (which you can
do from C# just as well). For that you need the FileSystem class in
assembly Microsoft.VisualBasic. VB6 "Open" statement corresponds to
FileSystem.Open, and "Input" corresponds to FileSystem.Input (and
"Line Input" corresponds to FileSystem.LineInput, in case you still
need that). It's likely that implementations of those methods
implement all quirks that might exist in VB6 input/output formats
better than you would be able to do on your own.
 
Just a general advice - please read my posts closer before posting.
You managed to find all kinds of things that weren't there...

The Microsoft.VisualBasic namespace has nothing to do with VB6, it is simply
a Net namespace like there is too Microsoft.Mshtml. This Net namespace add
some of the things which are a language part of VisualBasic but not standard
in in other Net program languages. There are not whatever plans to remove
this namespace ever from Net.
Click to expand...

Microsoft.VisualBasic namespace contains (among other things)
facilities that map to old features of VB6 language. Or else what do
you call FileSystem.FileOpen and LineInput methods? They're there so
that VB6 -> VB.NET converter can translate VB6 statements as directly
as possible; there's no other reason. In that sense, they're clearly
"compatibility" features.

By the way, I didn't say that there are any plans to remove them
from .NET. But I hope you'll agree that it's unwise to use them (from
C# or VB or any other language) except when you absolutely need to get
the precise behavior exhibited by VB6.
This VisualBasic namespace can be used within any Net program language like
any other namespace and are true Net without problems that they can become
forever not foreward compatible.
Click to expand...

You could guess that I'm aware of the fact from observing that
suggested to use a class from that namespace from C# in my original
post...
 
Pavel,

You reply shows exactly what I wanted to say and I have read your message
very intensively.

The Microsoft.VisualBasic namespace has absolute nothing to do with VB6
beside the fact that VB6 is a version from Visual Basic like C# 3 is a
version from C#. C# has only Net versions.

VB6 is based on a very integrated way of using Com objects and that is why
the Microsoft.VisualBasic.Compatibility.VB6 namespace exist.

Most of the things in the VisualBasic namespace are older than VB6 and
contains things which are simply in the language specifications of Visual
Basic independent from VB6. This is often misunderstood and completely wrong
written on Internet most often strange enough by persons who only use C#.

Because of that Com integration in VB6, you cannot get absolute behaviour as
VB6 in VB7, that is why all VB6 programs are converted as you go to a higher
version then VB6.

However, as you don't want to know this, no problem, but please don't
distribute the culllprit like you did, that is done already too often.

Cor
 
Cor, for the record, I earned my first MCP cert for VB6; I know what
it is quite well, no need to explain the basics to me.

The Microsoft.VisualBasic namespace has absolute nothing to do with VB6
beside the fact that VB6 is a version from Visual Basic like C#  3 is a
version from C#.  C# has only Net versions.
Click to expand...

I have already pointed out specific members of that namespace that
have everything to do with VB6 compatibility, and are worthless
outside of it. They are not encountered in idiomatic VB.NET code
otherwise.
Most of the things in the VisualBasic namespace are older than VB6 and
contains things which are simply in the language specifications of Visual
Basic independent from VB6.
Click to expand...

This is obviously wrong, considering that VB6 did not have
"namespaces" at all, and most certainly didn't have
Microsoft.VisualBasic namespace. It also didn't have methods called
"FileOpen" or "LineInput" - instead, "Open" and "Line Input" were core
statements in VB6 and before (and the BASIC dialects from which it is
derived). As such, syntactically, they looked quite different from
method calls, too.

Furthermore, the "language specification" for VB6 (which didn't really
exist as a single self-consistent document at the time) is very, very
different from VB.NET. Even things that are superficially the same
come with different semantics, so considering those two languages
merely two different versions of one is a very big stretch. The only
common thing they have is that both are BASIC dialects.
 
Back
Top