\r\n with format into string?

[1984]

Hi,

I have inherited a VI which uses convoluted string concatenations I'd like to simplify with the format into string function. The problem I'm facing with is that the guy who wrote the VI separated the lines with the end of line constant (\r\n), but if I hit an enter in the format string field then its shows up as \n only in the result. See the snippet as an example.

I can change the format string field to \code display then write "%s\r\n%s\r\n%s\r\n%s" and the switch it back to normal, but that hides the information that its not a simple press of the enter key, but something different.

Is there a workaround which keeps the format string field readable but hits a \r\n?

(Actually now, as I'm typing this I realized that I dont even understand why the "enter" does not mean a \r\n. whats the reason behind this?)

thx!

[GerdW]

Hi 1984,

---

@1984 wrote:

Is there a workaround which keeps the format string field readable but hits a \r\n?

(Actually now, as I'm typing this I realized that I dont even understand why the "enter" does not mean a \r\n. whats the reason behind this?)

---

There is no workaround AFAIK!

The reason behind that \n vs \r\n might be a simple "one key gives exactly one char" approach: that's how keyboards used to work right from the beginning…

[1984]

https://www.ni.com/nl-nl/support/documentation/supplemental/21/labview-termination-characters.html

I find this very confusing. Doesnt seem to be a visually obvious difference between \r, \n and \r\n. They show up in the \code display mode but they dont look any different in the normal mode display.

Moreover the definition vs actual work dont seem to match. Eg: the carriage return moves the cursor to the beginning of the line. In my interpretation this should mean that

Hello\rWorld should show up as WorldHello, but it shows up as a new line.

The line feed: "moves the cursor down to the next line without returning to the beginning of the line"

So Hello\nWorld should end up as something like:

Hello

        World

This is why I thought ENTER is actually \r\n

[thols]

That there is no visual difference is probably because they nowadays mean the same thing. And for compatibility, I guess. 

But I don't know why LabVIEW uses LF. Mac OS, which LabVIEW was created on seems to have used CR and Windows uses CR+LF. Unix uses LF.

This could be a history lesson:

https://en.wikipedia.org/wiki/Newline

[GerdW]

Hi 1984,

---

@1984 wrote:

Moreover the definition vs actual work dont seem to match. Eg: the carriage return moves the cursor to the beginning of the line. In my interpretation this should mean that

---

That is the definition how it used to work with those old mechanical printers/terminals: you can feed the paper one line down (LineFeed, \n) and you can move the print head to the beginning of the line (CarriageReturn, \r).

In any text editor I worked with so far that difference is neglected: using the enter key will move the cursor to the beginning of the next line. The difference between \r, \n and \r\n is due to OS concerns: UNIX is happy with just \n, while Windows prefers \r\n.

[AeroSoul]

They actually all give the same results in normal display, but the codes display says what it should.

Normal display:

Codes:

[thols]

If you create a string with two lines in LabVIEW, and then copy that string to e.g. Notepad++, you can see that the line break will be CR+LF, regardless of what you use as line separator:

But if you write the string to a file and do not convert EOL, you can get the LF out:

In the link you gave, the overview states "...they appear to have the same result – a line break. However, at the operating system level, each character is interpreted differently". The descriptions below that explain how they are interpreted by the OS. But after that, what happens to the text? they are probably displayed by e.g. Word or Notepad, and they will not care about the old mechanical meaning of LF and CR. But an instrument could depend on it. Here I would have liked to link to a word processor that actually does care about the difference, but I don't know one.

[1984]

Thanks folks! 

[RavensFan]

Remember that with an old typewrite or line printer, you could theoretically do a carriage return and not a line feed  (actually typewriters did both when slid the the bar, but you could always wind it back up a line).  If you did just a carriage return,  it would not have looked like WorldHello.  It couldn't move what had already been typed.  The result would have been World overtyping the word Hello    W on top of H, o on top of e, etc.

That is impossible with computers so the two codes effectively became the same thing.

Also think about the backspace character.  On old typewriters you could press a key and back up the carriage by a character.  You needed to do that if you needed to go underline something.   Now on computers, that would be like moving the cursor backwards but there are already arrow keys for that.  So Backspace now means backup a character and remove that character.

[Kyle97330]

If you build a normal, legible string, there's a string manipulation VI that ships with LabVIEW but not included on the palettes by default.

You can find it here:

LabVIEW 20xx\vi.lib\AdvancedString\Normalize End Of Line.vi

From the snippet you post it looks like you're using 2014.  I know for sure it was included in 2015 and beyond, but I don't know if it was there in 2014.

Normalize end of line VI help 

So you could build the string up legibly without switching to the "slash" view, then run it through that VI instead of what you're currently doing.