LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Search/Split String Function" behaves differently for string constant vs control

Solved!
Go to solution

I have observed some unusual behavior with the "Search/Split String Function", and would love some help to learn why and/or how to work-around this issue. 

 

Behavior:

1. When the "Search/Split String Function" is given a 'newline' (\n) delimited string constant, it is able to correctly parse and return the first token before the newline delimiter.

2. However, when the "Search/Split String Function" is given the exact-same 'newline' delimited string through a 'string control' (i.e. a string input text field), it is incapable of finding any 'newline' delimiters.

 

I have attached a minimal example from Lab View 2018 patch 2 (18f2) that demonstrates the issue.

 

Question 1: Does anyone know what's going on? Is this a bug, or am I missing something obvious, like some function parameter or string-encoding?

 

Question 2 (which is less important): I would ultimately like to use the "Search/Split String Function" to split on a null character ('\0'). I know some other LabView string functions do NOT work with the null character. Does anyone know if this "Split String Function" works on null characters?

 

- Thanks!

0 Kudos
Message 1 of 6
(4,109 Views)
Solution
Accepted by davidcw

No bugs, just a misunderstanding about the various string display modes and how each format represents your actual string characters.

 

For your constant, you added "\n" into a string that was in "Normal display mode".  That's really a "\\n".  You did the same thing for the "\n" you were searching for (really a "\\n").  So hear you have a match.

 

For your indicator you switched the control's display mode to "\ code display", and there you see the "\n" (LF).  Note there's no extra slash, so when you search for a "\\n" string it doesn't find one.  Everything works as it should, just not as you intended.

 

I suggest playing with the various string display modes a bit more, and also using the provided LabVIEW LF primitive.

  

SplitStringTest_displaymodemismatch.png

 

Message 2 of 6
(4,100 Views)

Wow! Thanks for your quick reply! Of course, you solved the problem.

 

I can't believe I didn't think to check whether string constants also have display modes. I will also certainly look into using the linefeed constant.

0 Kudos
Message 3 of 6
(4,092 Views)

Glad it helped, its one of those common gotchas.

 

As to Question #2, I'd convert to Hex and and search for \00 (NULL in Hex).  But you'll want to test that.

0 Kudos
Message 4 of 6
(4,083 Views)

Since you are using a relatively recent LabVIEW version, I strongly recommend to make the display style visible whenever it is not normal. This avoids a lot of mistakes.

 

(Also see this idea from 2009, now implemented :D)

 

DisplayStyle.png

Message 5 of 6
(4,067 Views)

Great Tip. Showing the display style will certainly reduce confusion.

0 Kudos
Message 6 of 6
(4,051 Views)