Format Into String and Scan From String bug

[tbob]

R&D may think it is expected behavior, but it certainly is not accepted behavior.  This case needs to be re-opened and examined by someone who has some sense of what Labview programmers do. 

All that needs to be done is for the Edit function to recognize that the string is coming from either the Normal display or the \ codes display, and act accordingly.  Right now, it acts as if the string was always from a normal display which is wrong.  In Mathew's case, the string was a \codes display.  Please ask R&D to reconsider.

[RavensFan]

I agree with you TBob.

The Edit function could be a very powerful tool to build custom formats without search through 3-4 different help files to find the appropriate codes.  But if it can't be used because it corrupts perfectly legitmate codes, then the tool is useless.

[tst]

The problem is that the dialog box does not support either backslash codes display or the display of non-printable characters, and so it corrupts existing strings. This is a considerable usability issue with bug creating potential and I'm surprised I never ran into this myself. I would also agree that the dialog needs to be upgraded to either handle \ codes or allow the input of special characters.

[Jennifer_R]

Any time a non-displayable character is represented with its '\' code in Normal Display, it will appear with a double backslash in '\' Codes Display.  This is true whether or not Edit Format String or Edit Scan String are used.  However, if the actual carriage return and newline are part of the format string, the representation in '\' Codes Display will be with a single backslash.  As tst alluded to, the real issue is that Edit Format String and Edit Scan String replace the actual carriage return and newline with their escape sequences. 

Despite the different representations, the resulting strings should be the same.  If you feel LabVIEW could be improved by handling non-displayable characters differently, I'd invite you to submit a product suggestion.  Thank you everyone for your input. 

[tst]

Ah, I didn't realize the actual string coming out of the function is the same even if the format string is different. It looks like the function can parse both \n \\n as newlines.

That's interesting, but I didn't manage to figure out exactly how it works. For example, these strings produce exactly the same result even though one has an extra backslash. I also didn't understand how many backslashes you actually need for this to work.

[Matthew_Kelton]

The issue then is that these two primitives treat a normal string like a \codes string.  So if I type \r in normal display, Format and Scan treat it as a carriage return instead of the two characters.  I just checked and saw Match pattern does the same thing.  The function treats "\r" as a carriage return in either normal or \ codes display.

I never realized this and find it an odd functionality decision.

[tbob]

So if I have a string control with normal display and I type "Mary had a little lamb\rThis is the second sentence.", and send it to a string indicator, then I will get two lines in the string indicator?  Or does it just interperate \r when using one of the string functions?  (I don't have time to experiment right now)

[Matthew_Kelton]

In the testing I did, only as inputs to these funtions.  For Format and Scan, just the format string, not any of the token inputs.

[RavensFan]

I came across this situation again today with LabVIEW 2009.  This bug has still not been fixed.