Data Types: String vs. SubString

[CoastalMaineBird]

LV2018 SP1.

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

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.

[rolfk]

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).

[RavensFan]

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.

[GerdW]

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.)

[rolfk]

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

[RavensFan]

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"?

[rolfk]

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.

[RavensFan]

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.

[rolfk]

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.

[crossrulz]

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.