Newline in Text Property

  • Thread starter Thread starter runningdog
  • Start date Start date
R

runningdog

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
 
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
 
Hi RunningDog:
runningdog said:
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
Click to expand...
Try either Environment.NewLine (for a truly .NET language independent
approach) or ControlChars.CrLf
 
Hi Bill,
Try either Environment.NewLine (for a truly .NET language independent
approach) or ControlChars.CrLf
Click to expand...

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
 
Hi Bill,


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
Click to expand...

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.
 
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
 
* "runningdog said:
I would like to be able to embed a newline in a text string.
Is there any convienent notation to do this
Click to expand...

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

\\\
MsgBox(String.Format("Foo{0}Bar{0}Baz{0}", ControlChars.NewLine))
///
 
* Tom Shelton said:
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.
Click to expand...

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>
 
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
 
* Tom Shelton said:
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.
Click to expand...

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>
Click to expand...

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 said:
When running code on Linux under mono, Environment.NewLine returns
a character of value 10 - an LF :)
Click to expand...


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
 
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.
Click to expand...

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 said:
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?
Click to expand...

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
 
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.
Click to expand...

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 :)
 
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)
 
There is no platform specific standard.
Click to expand...

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 said:
I'm not sure what you mean be standard?
Click to expand...

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.
Click to expand...

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 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".
Click to expand...

And that is pretty much the case. There are exceptions of course, but
the general rule on DOS is CR/LF and *nix LF.
Where does "it" expect it?
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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
 
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
 
Back
Top