469,623 Members | 1,437 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,623 developers. It's quick & easy.

Newline in Text Property

Hi,

I would like to be able to embed a newline in a text string.
Is there any convienent notation to do this

TIA Steve
Nov 20 '05 #1
29 3196
Hi RunningDog,

You mean something as (not tested only typed in here)
\\\
dim newstring as new system.text.stringbuilder(mystring.substring(0,10) )
newstring.append(vbcrlf)
newstring.append(mystring.substring(10))
mystring = newstring.toString
///

I hope this helps?

Cor
Nov 20 '05 #2
Hi RunningDog:
"runningdog" <ru********@reply.to.newsgroup> wrote in message
news:40***********************@lon-reader.news.telstra.net...
Hi,

I would like to be able to embed a newline in a text string.
Is there any convienent notation to do this

TIA Steve

Try either Environment.NewLine (for a truly .NET language independent
approach) or ControlChars.CrLf
Nov 20 '05 #3
Hi Bill,
Try either Environment.NewLine (for a truly .NET language independent
approach) or ControlChars.CrLf


What do you mean with the sentence ".Net language independent". When you are
using VB.net you are using a .Net language, what has that to do with
language independent?

Cor
Nov 20 '05 #4
On 2004-04-20, Cor Ligthert <no**********@planet.nl> wrote:
Hi Bill,
Try either Environment.NewLine (for a truly .NET language independent
approach) or ControlChars.CrLf


What do you mean with the sentence ".Net language independent". When you are
using VB.net you are using a .Net language, what has that to do with
language independent?

Cor


It's more of a platform specific rather then a "language independent"
thing... For example - on Linux and Unix systems the new line character
is a LF rather then a CRLF. By using System.Environment.NewLine rather
then ControlChars.CrLF you can write code that will be portable if you
ever have to run it on a *nix environment, such as mono.

--
Tom Shelton [MVP]
Powered By Gentoo Linux 1.4
Ninety percent of everything is crap.
-- Theodore Sturgeon
Nov 20 '05 #5
Hi Tom,

Much to late for you and Bill, and I expected another answer from Bill? When
I wrote it I was also thinking about you (that is for me equivalent to mono)
however I did want to avoid that in my question. Maybe you see that now in
my text.

Pitty although I knew that this answer could come from you it and it was
happening.

:-))))

Cor
It's more of a platform specific rather then a "language independent"
thing... For example - on Linux and Unix systems the new line character
is a LF rather then a CRLF. By using System.Environment.NewLine rather
then ControlChars.CrLF you can write code that will be portable if you
ever have to run it on a *nix environment, such as mono.

Nov 20 '05 #6
* Tom Shelton <to*@mtogden.com> scripsit:
It's more of a platform specific rather then a "language independent"
thing... For example - on Linux and Unix systems the new line character
is a LF rather then a CRLF. By using System.Environment.NewLine rather
then ControlChars.CrLF you can write code that will be portable if you
ever have to run it on a *nix environment, such as mono.


Where did you read that?

There is a contradiction in the documentation for 'Environment.NewLine':

<msdn>
Gets the newline string defined for this environment.
[...]
Property Value
A string containing "\r\n".
</msdn>

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #7
* "runningdog" <ru********@reply.to.newsgroup> scripsit:
I would like to be able to embed a newline in a text string.
Is there any convienent notation to do this


'ControlChars.NewLine', 'Environment.NewLine', 'vbNewLine'.

\\\
MsgBox(String.Format("Foo{0}Bar{0}Baz{0}", ControlChars.NewLine))
///

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #8
Thanks for the responces.
I was looking for something along the lines of the inline substitution
provide by Unix scripting languaages and some C libraries.

eg .
\b Backspace
\c Prints line without newline
\f Form feed
\n Newline
\r Carriage return
\t Tab
\v Vertical tab
\\ Backslash
\n The 8-bit character

echo "some text\n\n\nmore text ?\c"
some text
more text ?_

Steve

"runningdog" <ru********@reply.to.newsgroup> wrote in message
news:40***********************@lon-reader.news.telstra.net...
Hi,

I would like to be able to embed a newline in a text string.
Is there any convienent notation to do this

TIA Steve

Nov 20 '05 #9
In article <c6************@ID-208219.news.uni-berlin.de>, Herfried K. Wagner [MVP] wrote:
* Tom Shelton <to*@mtogden.com> scripsit:
It's more of a platform specific rather then a "language independent"
thing... For example - on Linux and Unix systems the new line character
is a LF rather then a CRLF. By using System.Environment.NewLine rather
then ControlChars.CrLF you can write code that will be portable if you
ever have to run it on a *nix environment, such as mono.


Where did you read that?

There is a contradiction in the documentation for 'Environment.NewLine':

<msdn>
Gets the newline string defined for this environment.
[...]
Property Value
A string containing "\r\n".
</msdn>


That's because MS.NET only runs on Windows :) Look in the Remarks
section:

The property value is a constant customized specifically for the
current platform.

When running code on Linux under mono, Environment.NewLine returns a
character of value 10 - an LF :)

--
Tom Shelton [MVP]
Nov 20 '05 #10
"Tom Shelton" <to*@mtogden.com> schrieb
When running code on Linux under mono, Environment.NewLine returns
a character of value 10 - an LF :)

Newline for /what/? I don't think it is platform specific at all. Sometimes
I get text files where only CR is used for a new line, sometimes CRLF,
sometimes LFCR... Or is environment.newline a new-line to be used within a
textbox? Or wherever? I think it depends on the individual case which char
or combination is used, and this is totally independent from the platform.

--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

Nov 20 '05 #11
In article <40***********************@news.freenet.de>, Armin Zingler wrote:
"Tom Shelton" <to*@mtogden.com> schrieb
When running code on Linux under mono, Environment.NewLine returns
a character of value 10 - an LF :)

Newline for /what/? I don't think it is platform specific at all. Sometimes
I get text files where only CR is used for a new line, sometimes CRLF,
sometimes LFCR... Or is environment.newline a new-line to be used within a
textbox? Or wherever? I think it depends on the individual case which char
or combination is used, and this is totally independent from the platform.


Remarks:

The property value is a constant customized specifically for the
current platform.

*nix systems use a LF as there new line character. Windows uses a CrLf.
I'm not sure who uses the LfCr - maybe Macs? Anyway, the point is that
is platform specific. Open up a text file generated by any windows program
on a *nix platform with vi... Your going to see 1 big line separated
with a lot of ^M characters :)

I'm only pointing out that it is more portable to use
System.Environment.NewLine then it is to use ControlChars.CrLf. Just as
it was more portable to use vbNewLine in VB6 - another supposedly
platform nuetral character contant (though, VB6 didn't run anything else
but windows :)

--
Tom Shelton [MVP]
Nov 20 '05 #12
"Tom Shelton" <to*@mtogden.com> schrieb
In article <40***********************@news.freenet.de>, Armin Zingler
wrote:
"Tom Shelton" <to*@mtogden.com> schrieb
When running code on Linux under mono, Environment.NewLine
returns a character of value 10 - an LF :)

Newline for /what/? I don't think it is platform specific at all.
Sometimes I get text files where only CR is used for a new line,
sometimes CRLF, sometimes LFCR... Or is environment.newline a
new-line to be used within a textbox? Or wherever? I think it
depends on the individual case which char or combination is used,
and this is totally independent from the platform.


Remarks:

The property value is a constant customized specifically for the
current platform.

*nix systems use a LF as there new line character. Windows uses a
CrLf. I'm not sure who uses the LfCr - maybe Macs?


But that's just what I wanted to say. You can not say "Windows uses...",
"Mac uses...". You can only say "The creator of the file uses...", or "the
textbox expects...". There is no platform specific standard.

--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

Nov 20 '05 #13
In article <40***********************@news.freenet.de>, Armin Zingler wrote:
"Tom Shelton" <to*@mtogden.com> schrieb
In article <40***********************@news.freenet.de>, Armin Zingler
wrote:
> "Tom Shelton" <to*@mtogden.com> schrieb
>> When running code on Linux under mono, Environment.NewLine
>> returns a character of value 10 - an LF :)
>
>
> Newline for /what/? I don't think it is platform specific at all.
> Sometimes I get text files where only CR is used for a new line,
> sometimes CRLF, sometimes LFCR... Or is environment.newline a
> new-line to be used within a textbox? Or wherever? I think it
> depends on the individual case which char or combination is used,
> and this is totally independent from the platform.
>


Remarks:

The property value is a constant customized specifically for the
current platform.

*nix systems use a LF as there new line character. Windows uses a
CrLf. I'm not sure who uses the LfCr - maybe Macs?


But that's just what I wanted to say. You can not say "Windows uses...",
"Mac uses...". You can only say "The creator of the file uses...", or "the
textbox expects...". There is no platform specific standard.


New lines are platform specific. Hence the fact that an ASCII mode ftp
transfer will translate newline characters into the recieving systems
format - which reeks havoc on binary files :)

--
Tom Shelton [MVP]
Nov 20 '05 #14
"Tom Shelton" <to*@mtogden.com> schrieb

New lines are platform specific.


There is no platform specific standard.
--
Armin

Nov 20 '05 #15
Well, you could put the "inline substitution" in your text and in your
VB code replace them with the <cr> <lf>. For instance:

dim myText as string = "some text\n\n\nmore text"
myText = myText.Replace("\n", vbcrlf)
runningdog wrote:
Thanks for the responces.
I was looking for something along the lines of the inline substitution
provide by Unix scripting languaages and some C libraries.

eg .
\b Backspace
\c Prints line without newline
\f Form feed
\n Newline
\r Carriage return
\t Tab
\v Vertical tab
\\ Backslash
\n The 8-bit character

echo "some text\n\n\nmore text ?\c"
some text
more text ?_

Steve

"runningdog" <ru********@reply.to.newsgroup> wrote in message
news:40***********************@lon-reader.news.telstra.net...
Hi,

I would like to be able to embed a newline in a text string.
Is there any convienent notation to do this

TIA Steve


Nov 20 '05 #16
In article <40***********************@news.freenet.de>, Armin Zingler wrote:
"Tom Shelton" <to*@mtogden.com> schrieb

New lines are platform specific.


There is no platform specific standard.


I'm not sure what you mean be standard? If your talking about a formal
standards body - then no, there isn't. But traditionally on *nix a
newline is a single lf (I know I said CR earlier). It's one of those
issues that tends to bite people when writing cross platform code. *nix
progams will almost always assume that a line terminates on LF, windows/dos
expects a cr/lf.

I'm really not sure what the argument is about. The fact is that it
unless you have specific reasons, I find that it is better not to
hardcode your line termination to a specific value - ControlChars.CrLf -
but to use System.Environment.NewLine. That way, I don't have to worry
about the difference because it will just do the right thing based on
the underlying platform. Look in the VB6 docs for vbNewLine - it is
essentially the same thing.

--
Tom Shelton [MVP]
Nov 20 '05 #17
"Tom Shelton" <to*@mtogden.com> schrieb
In article <40***********************@news.freenet.de>, Armin Zingler
wrote:
"Tom Shelton" <to*@mtogden.com> schrieb

New lines are platform specific.
There is no platform specific standard.


I'm not sure what you mean be standard?


I guess, by saying "platform specific" you want to say that on platform X
char Y is always used as the line separator. This is what I'd call a
"standard".
If your talking about a
formal standards body - then no, there isn't. But traditionally on
*nix a newline is a single lf (I know I said CR earlier). It's one
of those issues that tends to bite people when writing cross platform
code. *nix progams will almost always assume that a line terminates
on LF, windows/dos expects a cr/lf.
Where does "it" expect it? This sounds as if on my system everywhere CRLF is
always used, but this is not true. Consequently I can not always expect
CRLF. Consequently it doesn't make sense to prefer one of the constants over
the others because you have to decide it in each individual case. Moreover,
even if you read the /same/ file (e.g. using CRLF as the seperator) on two
different platforms, and on both systems Environment.newline is expected as
the seperator when reading the file, it doesn't help you at all. The
opposite is the case because on one system the wrong char is expected and
the file will be read wrong. Consequently, you always have to know which
seperator has been used for writing exactly this file that you are reading.
In addition, even if you know that CRLF had been used, do you know that the
programmer writing the file used Environment.Newline? Or did he use
vbNewLine? In the end it is out of interest. The only reason to prefer one
constant over the other is that you defined your own standard or your
company's standard that says that "we use environment.newline to write
files". But you could also say "we use vbNewline" - or whatever. None is
preferrable. Also, other companies might use other standards - or other
platforms. That's why I think that saying "new lines are platform specific"
is not right.
I'm really not sure what the argument is about. The fact is that
it unless you have specific reasons, I find that it is better not
to hardcode your line termination to a specific value -
ControlChars.CrLf - but to use System.Environment.NewLine. That way,
I don't have to worry about the difference because it will just do
the right thing based on the underlying platform. Look in the VB6
docs for vbNewLine - it is essentially the same thing.



--
Armin

Nov 20 '05 #18
In article <40***********************@news.freenet.de>, Armin Zingler wrote:
"Tom Shelton" <to*@mtogden.com> schrieb
In article <40***********************@news.freenet.de>, Armin Zingler
wrote:
> "Tom Shelton" <to*@mtogden.com> schrieb
>>
>> New lines are platform specific.
>
> There is no platform specific standard.
I'm not sure what you mean be standard?


I guess, by saying "platform specific" you want to say that on platform X
char Y is always used as the line separator. This is what I'd call a
"standard".


And that is pretty much the case. There are exceptions of course, but
the general rule on DOS is CR/LF and *nix LF.
If your talking about a
formal standards body - then no, there isn't. But traditionally on
*nix a newline is a single lf (I know I said CR earlier). It's one
of those issues that tends to bite people when writing cross platform
code. *nix progams will almost always assume that a line terminates
on LF, windows/dos expects a cr/lf.


Where does "it" expect it?


Well it's built right into the standard libraries.
This sounds as if on my system everywhere CRLF is
always used, but this is not true.
There are exceptions - but they are willfull exceptions.
Consequently I can not always expect
CRLF. Consequently it doesn't make sense to prefer one of the constants over
the others because you have to decide it in each individual case.
If interoperability is the case - then yes, you have to make a decission.
Moreover,
even if you read the /same/ file (e.g. using CRLF as the seperator) on two
different platforms, and on both systems Environment.newline is expected as
the seperator when reading the file, it doesn't help you at all.
The
opposite is the case because on one system the wrong char is expected and
the file will be read wrong. Consequently, you always have to know which
seperator has been used for writing exactly this file that you are reading.
That is true. Believe me, I am very aware of this situation. When
dealing with cross platform data, you have to be aware of the format.
It is one of the banes of the newline problem and a lack of a universal
definition of a newline.
In addition, even if you know that CRLF had been used, do you know that the
programmer writing the file used Environment.Newline? Or did he use
vbNewLine? In the end it is out of interest. The only reason to prefer one
constant over the other is that you defined your own standard or your
company's standard that says that "we use environment.newline to write
files". But you could also say "we use vbNewline" - or whatever. None is
preferrable. Also, other companies might use other standards - or other
platforms. That's why I think that saying "new lines are platform specific"
is not right.


There are platform specific conventions. But, when interoperability
is the goal, then yes picking a specific line terminator and specifying
it is important. Because a programmer has to know what to expect when
reading the data on another platform. In those cases, I usually choose
a CR/LF - since windows is much more universal. But, as I said each
platform has it's own convention for line termination, here is the list
for the big 3:

DOS/Windows - CR/LF
*nix - LF
Mac (just looked this one up) - CR

--
Tom Shelton [MVP]
Nov 20 '05 #19
Hi Tom,

I did not wanted to start the discussion in this thread about the cr and lf

And therefore I stuffed this morning a much longer message than it was. My
point was that Bill said something about that .Net languages standards
wherin the VBCRLF was not.

This did sound for me again as an advice to use alone the single basic .Net
namespace in vb.net and not use the benefits from other .Net namespaces.

I too agree with Armin, that avoiding the vbcrlf looks for me as a Don
Quichot. It would be wise as only for that was used the LF however it is
not.

Just some thoughts,

Cor

Nov 20 '05 #20
In article <#N**************@TK2MSFTNGP12.phx.gbl>, Cor Ligthert wrote:
Hi Tom,

I did not wanted to start the discussion in this thread about the cr and lf

And therefore I stuffed this morning a much longer message than it was. My
point was that Bill said something about that .Net languages standards
wherin the VBCRLF was not.

This did sound for me again as an advice to use alone the single basic .Net
namespace in vb.net and not use the benefits from other .Net namespaces.

I too agree with Armin, that avoiding the vbcrlf looks for me as a Don
Quichot. It would be wise as only for that was used the LF however it is
not.

Just some thoughts,

Cor


I'm not trying to say avoid ControlChars - I'm saying I try not to hard
code the line terminator. I would suggest using ControlChars.NewLine, if
you want to use the VB.NET specific enumeration :) I'm not sure if it
will have the same behavior - since it doesn't seem to work on mbas yet
(the mono vb.net compiler) - but I suspect that it will.

--
Tom Shelton [MVP]
Nov 20 '05 #21
"Tom Shelton" <to*@mtogden.com> schrieb
In article <40***********************@news.freenet.de>, Armin Zingler
wrote:
"Tom Shelton" <to*@mtogden.com> schrieb
In article <40***********************@news.freenet.de>, Armin
Zingler wrote:
> "Tom Shelton" <to*@mtogden.com> schrieb
>>
>> New lines are platform specific.
>
> There is no platform specific standard.

I'm not sure what you mean be standard?
I guess, by saying "platform specific" you want to say that on
platform X char Y is always used as the line separator. This is
what I'd call a "standard".


And that is pretty much the case. There are exceptions of course,
but the general rule on DOS is CR/LF and *nix LF.


Despite these exceptions you are blindly using environment.newline?
If your talking about a
formal standards body - then no, there isn't. But traditionally
on *nix a newline is a single lf (I know I said CR earlier). It's
one of those issues that tends to bite people when writing cross
platform code. *nix progams will almost always assume that a line
terminates on LF, windows/dos expects a cr/lf.


Where does "it" expect it?


Well it's built right into the standard libraries.


I'm talking about conventions in general, not only about the Framework.
There are apps not built on the Framework.
This sounds as if on my system everywhere CRLF is
always used, but this is not true.


There are exceptions - but they are willfull exceptions.


Even if there was only 1 exception among 100,000 cases, I'd have to check
the format in each case.
Consequently I can not always expect
CRLF. Consequently it doesn't make sense to prefer one of the
constants over the others because you have to decide it in each
individual case.


If interoperability is the case - then yes, you have to make a
decission.


The file format - and this is only an example where line terminators are
used - is independent from managed code, unmanaged code, interop,
programming language ...
Moreover,
even if you read the /same/ file (e.g. using CRLF as the seperator)
on two different platforms, and on both systems Environment.newline
is expected as the seperator when reading the file, it doesn't help
you at all.
The
opposite is the case because on one system the wrong char is
expected and the file will be read wrong. Consequently, you always
have to know which seperator has been used for writing exactly this
file that you are reading.


That is true. Believe me, I am very aware of this situation.
When dealing with cross platform data, you have to be aware of the
format.


You /always/ have to be aware of the format, not only when dealing wit
hcross platfrom data.
It is one of the banes of the newline problem and a lack of a
universal definition of a newline.
Right, just because of this lack, you always have to know what to expect.
In addition, even if you know that CRLF had been used, do you know
that the programmer writing the file used Environment.Newline? Or
did he use vbNewLine? In the end it is out of interest. The only
reason to prefer one constant over the other is that you defined
your own standard or your company's standard that says that "we use
environment.newline to write files". But you could also say "we use
vbNewline" - or whatever. None is preferrable. Also, other
companies might use other standards - or other platforms. That's
why I think that saying "new lines are platform specific" is not
right.


There are platform specific conventions.


As long as there is no guarantee that a file (or the programmer writing the
file) obeys the convention, you can not blindly use environment.newline.
But, when interoperability
is the goal, then yes picking a specific line terminator and
specifying
it is important. Because a programmer has to know what to expect
when reading the data on another platform. In those cases, I usually
choose a CR/LF - since windows is much more universal. But, as I
said each platform has it's own convention for line termination, here
is the list for the big 3:

DOS/Windows - CR/LF
*nix - LF
Mac (just looked this one up) - CR


1. Even if you know the platfoom, you will fail if you rely on this. My
attitude is that a high probabibilty is not enough. That's why I say that I
have to check each case.
2. You sometimes don't know on which platform the file has been created. I
don't have to know it but I have to know the used seperator.
"Environment.newline" says absolutely nothing.
I also say this because I recently read a file using the streamreader
(readline method) and found out that the streamreader also recognizes a
single CR as a separator. Hmmm...... According to your definition it's a
bug, isn't it? (BTW, ran on a Win32 platform ;-) )
Sorry that my first post was a reply to *your's*. It should actually be a
general question/issue.

--
Armin

Nov 20 '05 #22
In article <40***********************@news.freenet.de>, Armin Zingler wrote:
"Tom Shelton" <to*@mtogden.com> schrieb
In article <40***********************@news.freenet.de>, Armin Zingler
wrote:
> "Tom Shelton" <to*@mtogden.com> schrieb
>> In article <40***********************@news.freenet.de>, Armin
>> Zingler wrote:
>> > "Tom Shelton" <to*@mtogden.com> schrieb
>> >>
>> >> New lines are platform specific.
>> >
>> > There is no platform specific standard.
>>
>> I'm not sure what you mean be standard?
>
> I guess, by saying "platform specific" you want to say that on
> platform X char Y is always used as the line separator. This is
> what I'd call a "standard".
>
And that is pretty much the case. There are exceptions of course,
but the general rule on DOS is CR/LF and *nix LF.


Despite these exceptions you are blindly using environment.newline?


Those exceptions are the cases where the programmer purposely overrode
the convention. I have never had that happen, since most people use the
standard IO conventions of there platform. And I only use
Environment.NewLine for output. Not for reading, espcially since
StreamReader is usually capable of descerning the source files newline
character.
>> If your talking about a
>> formal standards body - then no, there isn't. But traditionally
>> on *nix a newline is a single lf (I know I said CR earlier). It's
>> one of those issues that tends to bite people when writing cross
>> platform code. *nix progams will almost always assume that a line
>> terminates on LF, windows/dos expects a cr/lf.
>
> Where does "it" expect it?


Well it's built right into the standard libraries.


I'm talking about conventions in general, not only about the Framework.
There are apps not built on the Framework.


I'm not talking about the Framework either. I'm talking about the
standard system libraries on *nix and windows systems. I'm talking
about the low level IO.
> This sounds as if on my system everywhere CRLF is
> always used, but this is not true.


There are exceptions - but they are willfull exceptions.


Even if there was only 1 exception among 100,000 cases, I'd have to check
the format in each case.


In general, I think your going to find that the ratio is even smaller
then that.
> Consequently I can not always expect
> CRLF. Consequently it doesn't make sense to prefer one of the
> constants over the others because you have to decide it in each
> individual case.


If interoperability is the case - then yes, you have to make a
decission.


The file format - and this is only an example where line terminators are
used - is independent from managed code, unmanaged code, interop,
programming language ...


Yes. You have to be aware of what the terminator is going to be if you
getting data from other platforms. Like I said, usually when I do file
IO on *nix, the files are intended to be used with windows software - so
I generally use the CR/LF sequence in those cases.
> Moreover,
> even if you read the /same/ file (e.g. using CRLF as the seperator)
> on two different platforms, and on both systems Environment.newline
> is expected as the seperator when reading the file, it doesn't help
> you at all.
> The
> opposite is the case because on one system the wrong char is
> expected and the file will be read wrong. Consequently, you always
> have to know which seperator has been used for writing exactly this
> file that you are reading.


That is true. Believe me, I am very aware of this situation.
When dealing with cross platform data, you have to be aware of the
format.


You /always/ have to be aware of the format, not only when dealing wit
hcross platfrom data.


Not really - unless you specifically override the terminator. And there
would have to be a very good reason for me to do that if I knew the data
was going to another *nix system, since every standard tool on that
system is going to expect lf as the terminator character. The only time
that is in issue is if your dealing with different platforms.
It is one of the banes of the newline problem and a lack of a
universal definition of a newline.


Right, just because of this lack, you always have to know what to expect.


Yes - if your recieving data from other platforms, then yes you have to
be aware of the issue. I've never had a file from a windows source that
did not use the CR/LF convention.
> In addition, even if you know that CRLF had been used, do you know
> that the programmer writing the file used Environment.Newline? Or
> did he use vbNewLine? In the end it is out of interest. The only
> reason to prefer one constant over the other is that you defined
> your own standard or your company's standard that says that "we use
> environment.newline to write files". But you could also say "we use
> vbNewline" - or whatever. None is preferrable. Also, other
> companies might use other standards - or other platforms. That's
> why I think that saying "new lines are platform specific" is not
> right.
>


There are platform specific conventions.


As long as there is no guarantee that a file (or the programmer writing the
file) obeys the convention, you can not blindly use environment.newline.


The only time this is an issue is in recieving data. You have to know
when reading data what the terminator was when writing. As I said, most
of the time the data that I write on *nix is destined for windows boxes
- so I usually use a CR/LF explicitly so that the file will work with
the standard windows tools - such as notepad. I have noticed that
wordpad is smart enough to recognize a single lf though :)
But, when interoperability
is the goal, then yes picking a specific line terminator and
specifying
it is important. Because a programmer has to know what to expect
when reading the data on another platform. In those cases, I usually
choose a CR/LF - since windows is much more universal. But, as I
said each platform has it's own convention for line termination, here
is the list for the big 3:

DOS/Windows - CR/LF
*nix - LF
Mac (just looked this one up) - CR


1. Even if you know the platfoom, you will fail if you rely on this. My
attitude is that a high probabibilty is not enough. That's why I say that I
have to check each case.


In very, very few cases. I'm not advocating that you not check your
source file.
2. You sometimes don't know on which platform the file has been created. I
don't have to know it but I have to know the used seperator.
"Environment.newline" says absolutely nothing.
Of course not. It only tells you the newline character of the current
platform - not the one where the file originated. For cross platform
data - you do have to know the format it was written in. But the
newline character used is a very good indication of the originating
platform.

I also say this because I recently read a file using the streamreader
(readline method) and found out that the streamreader also recognizes a
single CR as a separator. Hmmm...... According to your definition it's a
bug, isn't it? (BTW, ran on a Win32 platform ;-) )


I don't think so. I think that ReadLine is a bit smarter then that. It
says in the docs that it looks for LF ("\n") or CRLF ("\r\n") as the
line terminator. Which means it is not soley using Environment.NewLine.

--
Tom Shelton [MVP]
Nov 20 '05 #23
"Tom Shelton" <to*@mtogden.com> schrieb

We've got different opinions, so I drop the quote this time. :-)

I also say this because I recently read a file using the
streamreader (readline method) and found out that the streamreader
also recognizes a single CR as a separator. Hmmm...... According to
your definition it's a bug, isn't it? (BTW, ran on a Win32 platform
;-) )


I don't think so. I think that ReadLine is a bit smarter then that.
It says in the docs that it looks for LF ("\n") or CRLF ("\r\n") as
the line terminator. Which means it is not soley using
Environment.NewLine.


I expect the streamreader to use the platform standard. A single CR is not
the platform standard.
Don't call this "smart", call it a bug. ;-)
--
Armin

Nov 20 '05 #24
In article <40***********************@news.freenet.de>, Armin Zingler wrote:
"Tom Shelton" <to*@mtogden.com> schrieb

We've got different opinions, so I drop the quote this time. :-)

It's ok to have differing oppions... That's what makes the world go
round :)
> I also say this because I recently read a file using the
> streamreader (readline method) and found out that the streamreader
> also recognizes a single CR as a separator. Hmmm...... According to
> your definition it's a bug, isn't it? (BTW, ran on a Win32 platform
> ;-) )


I don't think so. I think that ReadLine is a bit smarter then that.
It says in the docs that it looks for LF ("\n") or CRLF ("\r\n") as
the line terminator. Which means it is not soley using
Environment.NewLine.


I expect the streamreader to use the platform standard. A single CR is not
the platform standard.
Don't call this "smart", call it a bug. ;-)


Why? It means less work for me :)

--
Tom Shelton [MVP]
Nov 20 '05 #25
"Tom Shelton" <to*@mtogden.com> schrieb
I expect the streamreader to use the platform standard. A single CR
is not the platform standard.
Don't call this "smart", call it a bug. ;-)


Why? It means less work for me :)


It meant more work for me because I had CR *within* a line and I could not
use the streamreader therefore. What would have been your solution? I read
the whole file in a string and split it on my own (because the String.Split
function doesn't take /two/ chars as /one/ separator, and the VB.split
function occupied too much memory).
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

Nov 20 '05 #26
Armin!

* "Armin Zingler" <az*******@freenet.de> scripsit:
I expect the streamreader to use the platform standard. A single CR
is not the platform standard.
Don't call this "smart", call it a bug. ;-)


Why? It means less work for me :)


It meant more work for me because I had CR *within* a line and I could not
use the streamreader therefore. What would have been your solution? I read
the whole file in a string and split it on my own (because the String.Split
function doesn't take /two/ chars as /one/ separator, and the VB.split
function occupied too much memory).


I would expect a property where you can set the line terminator string
(defaults to 'Environment.NewLine').

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #27
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schrieb
It meant more work for me because I had CR *within* a line and I
could not use the streamreader therefore. [...]


I would expect a property where you can set the line terminator
string (defaults to 'Environment.NewLine').


Yep. That's what I was also looking for but I didn't find it.
--
Armin

Nov 20 '05 #28
* "Armin Zingler" <az*******@freenet.de> scripsit:
It meant more work for me because I had CR *within* a line and I
could not use the streamreader therefore. [...]


I would expect a property where you can set the line terminator
string (defaults to 'Environment.NewLine').


Yep. That's what I was also looking for but I didn't find it.


Alternatively, there could be an overload for 'ReadLine' which accepts
the separator character. Maybe that's not a good idea because it may
decrease the performance if the separator has to be passed in every
call.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #29
In article <40***********************@news.freenet.de>, Armin Zingler wrote:
"Tom Shelton" <to*@mtogden.com> schrieb
> I expect the streamreader to use the platform standard. A single CR
> is not the platform standard.
> Don't call this "smart", call it a bug. ;-)


Why? It means less work for me :)


It meant more work for me because I had CR *within* a line and I could not
use the streamreader therefore. What would have been your solution? I read
the whole file in a string and split it on my own (because the String.Split
function doesn't take /two/ chars as /one/ separator, and the VB.split
function occupied too much memory).


Interesting situation... Actually, that goes against the docs - since
it only mentions looking for a single lf or a cr/lf. So, maybe it could
be classified as a bug.

I think I agree with Herfried... There should be a property or some way
to override this behavior when it is undesirable. Of course, I've never
had text data that had a single CR embedded in the data that wasn't
meant as a newline :)

--
Tom Shelton [MVP]
Nov 20 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Quan Nguyen | last post: by
5 posts views Thread by Kaka | last post: by
10 posts views Thread by D Steward | last post: by
7 posts views Thread by Alex Nordhus | last post: by
4 posts views Thread by Peter Kirk | last post: by
5 posts views Thread by Adam Right | last post: by
11 posts views Thread by Michael | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.