Showing results for 
Search instead for 
Did you mean: 

Data Types: String vs. SubString

LV2018 SP1.


OK, this is my 30th year using LabVIEW, but I've never seen this before.StringBug Pic.PNG


It's actually complaining that it can't use a substring where a string is supposed to connect.


Attached is the VI.  If you pop up on the bad wire and INSERT a CONCAT STRINGS function, the error disappears.


It actually can't connect a (sub)string output to a string input.



Steve Bird
Culverson Software - Elegant software that is a pleasure to use.

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 15

Compiler bug. The compiler should be able to automatically promote a substring to a string if it determines that it is needed. Function node inputs can declare what type of (sub)types they can deal with and there are reasons why a function may decide that a substring is not safe (for instance when it somehow needs to modify the string) but the compiler should be smart enough to add an implicit substring to string conversion (yes a full data copy) when the input requires that.

The Always Copy node should fix it too (this is basically what they compiler should add implicitly to turn the substring to a string).


Rolf Kalbermatter
My Blog
Message 2 of 15

Very interesting.  A typecast works in there also.


What else is interesting is that if you create an indicator off of the Match Pattern outputs, Context Help reports the data type as string.  All the terminals report in Context Help they are type (string) when you hover over them.  If you create a constant off the outputs, which should give you a datatype that is equal to the output, and wire that up to the TDMS Read function, it connects just fine.


Only the direction connection gives a broken wire.



0 Kudos
Message 3 of 15

Hi Steve,


the same compiler problem 7 years earlier with LV2011:


(The same happens with LV2009, so the same compiler bug is present since atleast 9 years before your LV2018.)

Best regards,

using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 4 of 15

A constant never can be a substring. What string should it reference too?

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 15

What exactly is a "(Sub)string"?  Why is the "sub" part put in parentheses?  To me that implies the "sub" part is optional.


What is "string" vs. "Substring"  vs. "(Sub)string"?

0 Kudos
Message 6 of 15

A sub string is a special type of string. Instead of containing the actual string it contains a reference to the original string and extra information such as offset into that original string and length. You also have sub arrays with the same idea only there are a few more options such as inverse order, transposed 2D array, etc.


It's mainly a way to reduce memory copies and also improve performance since many consumers downstreams are pretty happy with just reading the actual string information and the LabVIEW compiler than "only" has to make sure that these consumers are scheduled before any function that might modify the original string.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 15

But when the help puts parentheses around the "sub" part, that is implying some sort of option to the "sub", like it could be string or it could be substring and it doesn't care.  Yet it does care.

0 Kudos
Message 8 of 15

In principle they should be interchangable. The compiler should be able to determine which type a sink needs and translate automatically. Not sure why the TDMS function seems to cause a problem there. Also the decision if a function output produces a subtype rather than the normal type can be theoretically dynamic based on runtime parameters.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 15

Opened your VI in 2019SP1.  I did a Diagram Cleanup (Ctrl+U) and then undo.  The wire is fixed!  But try to run and you get the error dialog complaining about that wire.  Definitely a bug.


And, yes, the Always Copy fixed it as well.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 15