extra space in end of line constant

[Neil.Pate]

Hello All,

Does anyone have an explanation why when using an end of line constant and a format into string there is an "apparent" extra space included?

The attached VI (LV 8.5) shows the behaviour. There should not be a space after the "e", but there appears to be. If you view the string in hex form there is clearly not an extra space character. What is going on here, am I misinterpreting how this is supposed to work?

[PhillipBrooks]

I think this is normal; just confirmed by testing this all the way back to LV 6.1. Note that the help states that this is the platform dependant end-of-line termination character. Windows uses CR/LF which is two characters.

http://en.wikipedia.org/wiki/End_of_line

[Neil.Pate]

Phillip,

I agree with you that the end of line constant is platform dependent and two chars under windows (0x0D 0x0A), and this is what I see in the hex string, which is as expected. It is the extra "space" after the "e" character that I am disagreeing about. The EOL should not be two characters in normal string view, only in hex view. There is a space attached to the end of the line before the linefeed and carriage return does its magic and starts the next line. This extra space is not present in the hex string.

[TCPlomp]

Hi nrp,

Man I was trigger happy.
I see what you mean, if you step through the 'normal' string you will notice their's a position after the 'e' before going to the next lin.

This was my original reply (humble, humble)
I don't really get what you mean but I think you need to remember the 'hex' view is a formatted view, with an additional space after every second character!
The function returns this for me:

Which is totally acceptable for me. I see 5 characters ('o','n','e','CR','LF')

Ton


Message Edited by TonP on 12-27-2007 04:47 PM

Message Edited by TonP on 12-27-2007 04:49 PM

[Neil.Pate]

Ton,

The point I am trying to get across, is as you mentioned there is an extra space in the normal string.

I agree 100% with the hex view, including the spaces in the hex view separating the double characters, I am not arguing that.

The attached picture may explain what I mean.

There shouldn't be a space in the normal string, there is certainly not a space character, 0x20, in the hex string!

[TCPlomp]

Yes nrp,

I agree, not sure what it is, since the 'String' property doesn't return the 'space'
Here's your picture inline:


Ton

[Matthew_Kelton]

---

@nrp wrote:

The EOL should not be two characters in normal string view, only in hex view.

---

The EOL should be 2 characters, because it is 2 characters, regardless of your view.  They are supposed to be non-printing characters in normal view, but shoud be there regardless.  Although Windows has destroyed their meaning, a \r should take you back to the begging of the current line.  The \n should take you to the next line in the same position you are in on the current line.  The proper EOL should be \r\n if you want to be at the beginning of the next line.

LabVIEW is not properly handling the \r\n EOL (at least in Windows).  If you take either the \r or \n off, then LabVIEW goes to the next line.  If you put them together, in any order, then LabVIEW displays the first one as a space, then treats the second one as a new line.  It's definitely a bug in the handling of the string.

[waldemar.hersacher]

I have made a little bit of testing.

The '0D' character is displayed as a space. You can delete the 'space' and then read out the string using a local variable. Displaying the string in hex you can see that the '0D' character has been deleted.

[Matthew_Kelton]

---

@waldemar.hersacher wrote:

The '0D' character is displayed as a space.

---

Only if it is first.  Change the string so it is 0A 0D instead of 0D 0A.  The 0A will be displayed as the space.

[Neil.Pate]

I think you were misunderstanding my meaning, I was not trying to say that an EOL on windows is not two characters, it is by definition. Just in normal viewing (i.e. normal ascii), an EOL should not appear as two characters.

However we all seem to agree on the net result, this would appear to be erroneous.