From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Concatenating Terminal Control Reference
@Darin.K wrote:
Treating scalar concatenation like indexing is probably the most intuitive, but I would argue that the most consistent treatment would be to treat it as 'last value'. Indexing raises the dimensionality, concatenation keeps it the same so I would say scalar in gives scalar out.
There is one exception, and that is this one which baffles me:
I am tired of tossing U8 conversions or a concatenate strings function in there. Strings are definitely the one scalar data type where there is no confusion about what 'concatenate' means....
Well that is one where I alwways use concatinate strings OUTSIDE the loop. But having that inside the tunnel would be rich The datatype is known and Concatinate Strings is a cheap primitive "post loop"" or "in tunnel" should be equivallent.
@Darin.K wrote:
Treating scalar concatenation like indexing is probably the most intuitive, but I would argue that the most consistent treatment would be to treat it as 'last value'. Indexing raises the dimensionality, concatenation keeps it the same so I would say scalar in gives scalar out.
There is one exception, and that is this one which baffles me:
I am tired of tossing U8 conversions or a concatenate strings function in there. Strings are definitely the one scalar data type where there is no confusion about what 'concatenate' means....
If you would stop thinking like a "real" programmer, this would not baffle you. Strings are magical scalers of undefined size that show up in memory as uniform text... not arrays of bytes that grow in memory as you add to them.
parthabe wrote:Is this option not available in LV 2010?
Both the concat feature on tunnels and the conditional indexing option were added in 2012.
Greg, I think I'm having a flashback moment:
@BowenM wrote:
@Darin.K wrote:
Treating scalar concatenation like indexing is probably the most intuitive, but I would argue that the most consistent treatment would be to treat it as 'last value'. Indexing raises the dimensionality, concatenation keeps it the same so I would say scalar in gives scalar out.
There is one exception, and that is this one which baffles me:
I am tired of tossing U8 conversions or a concatenate strings function in there. Strings are definitely the one scalar data type where there is no confusion about what 'concatenate' means....
If you would stop thinking like a "real" programmer, this would not baffle you. Strings are magical scalers of undefined size that show up in memory as uniform text... not arrays of bytes that grow in memory as you add to them.
Regardless of the way it's represented and handled, I agree with Darin that a concat option on a string is clear, especially when you consider that LV had concat for strings long before it had concat for arrays. That said, the lack of it doesn't bother me because a) I don't do this that often and b) the "concat the array of strings" option is simple enough so that it doesn't pass the annoyance threshold.
@Darin.K wrote:
There is one exception, and that is this one which baffles me:
I am tired of tossing U8 conversions or a concatenate strings function in there. Strings are definitely the one scalar data type where there is no confusion about what 'concatenate' means....
There is this old idea, of course.
A scalar string wired to a concatenating tunnel should result in a concatenated string, while wiring an array of strings should concatenate the array of strings instead.
