Format Into String and Scan From String bug

[Matthew_Kelton]

I've run into this a couple of times an have always just dealt with it by not using NI's tool, but figured it should be posted here and referenced via the bug list.

The attached VI will demonstarte the issue.  I have wired the format string with \r\n:



Any of these codes (\r,\n, combination) will be corrupted if you select the "Edit Scan Stirng" option from the right-click context menu.  It doesn't matter the view of the string on the diagram.  The Edit Scan String utility will bring them in as literal strings "\r" and "\n" and when the user clicks OK, the \r and \n will be transformed into \\r and \\n:



The only workaround I am aware of is to not use the utility.  I have seen this problem at least going back to 6.1.




Message Edited by Matthew Kelton on 12-27-2007 01:13 PM

[tbob]

I just tried it in LV8.5, and the bug is still there.  I never used the Edit Format String option before.  I just simply use the text tool and edit the constant itself.

Even if you change the view to Normal Display, the bug still shows up.  I changed the view to Normal, used the Edit Format String function, and then changed the view back to \ codes, and the double slashes showed up.

[Jennifer_R]

Hi Matthew and tbob,

This is actually expected behavior since '\' is used to display special characters in format strings.  The text entered in the Edit Format String and Edit Scan String dialog boxes is as if you had entered the format string with Normal Display selected.  Changing to '\' Codes Display shows the backslash representation of that text, adding the extra backslash since "\\" is the code used to display the backslash character. 

You'll see the same behavior even if Edit Format String and Edit Scan String aren't used.  If the format string appears as "Hello\s%d\r\n" under Normal Display, it will appear as "Hello\s%d\\r\\n" under '\' Codes Display.  The resulting string and output should be the same with or without the second backslash.  If you search for "backslash codes display" in LabVIEW Help, you will find the topic "Backslash ('\') Codes Display" which shows an example of how the backslash character is represented in both display modes. 

Thanks for the feedback - it's always appreciated. 

[Matthew_Kelton]

Jennifer,

You didn't open the VI and test it, did you?  The strings are in \ displays in both cases.  All I did in my example was right-click and choose Edit Format String, then click OK.  The strings should not have changed at all in that case.  The character before was a \r (carriage return) and a \n (linefeed) in \ codes display.  The Edit Format String utility takes those strings and converts them to "\r" and "\n" in normal display, or "\\r" and "\\n" in \ codes display.

The Edit Format String utility corrupts the EOL characters when it brings them in.


Message Edited by Matthew Kelton on 12-28-2007 12:26 PM

[Jennifer_R]

Hi Matthew,

I did test the VI and saw the same behavior you reported.  However, Edit Format String and Edit Scan String output the exact string entered and do not recognize \r or \n as escape codes.  For LabVIEW to interpret those you must select '\' Codes Display.  By clicking OK you are changing the format string just as if you had selected Normal Display and changed the string constant on the block diagram. 

I understand that this isn't ideal and appreciate that you posted the information.  This was reported to R&D (# 4GRBPO0O) for further investigation. 

Thanks for your interest in helping to improve LabVIEW!

[Matthew_Kelton]

But, when I type the string in the block diagram as I did, the functions should interpret them correctly.  It's fine by me if they don't let me enter them into the window, but it gets a little frustrating when I have a 20 line header I'm filling out and there is an error in my string.  I use that tool to determine where my mistake is.  Then those 20 linefeeds get corrupted if I hit OK, whether I modify the string in the function or not.

[Jennifer_R]

Hi Matthew,

One possible workaround could be to locate the error using Edit Format String or Edit Scan String but then hit Cancel instead of OK.  This will leave the format string unchanged, allowing you to edit the string constant on the block diagram once you know where the error is.  Sorry for the inconvenience and frustration. 

I will post any updates that I receive from R&D. 

[Jennifer_R]

For anyone who might want to know the status later, this is currently being investigated by R&D as issue # 4GRCT90O.  Sorry for the confusion. 

[Jennifer_R]

This was reported to R&D (# 4GRCT90O), but was determined to be expected behavior for the reasons posted in message 3 above.

[Matthew_Kelton]

I would love to speak to the R&D person who thinks changing a \r to a \\r is acceptable since the two strings are not the same.