Add option to preserve string formatting when using the concatenation operator...

[sbus]

I'd like to see added to LabVIEW  a 'Retain String Formatting' option for the concatenation operator. This would cause string formatting (the stuff you set with the CTRL-0 shortcut) to be preserved when concatenated. See the example below. This could be added to the right-click properties of the concatenation operator "Preserve String Formatting". An alternate symbol for concatentation would need to be provided so that you could visually tell that this option was enabled when looking at the concatenation operator on the block diagram. Maybe the NBC peacock sitting on top of it?

Sometimes setting string formatting attributes programmatically is a lot of work, and inappropriate to the application; simply not changing/removing the attributes would be sufficient... Note that the string formatting attributes are preserved across a cut-and-paste - if you copy the contents of a formatted string and paste it into another string, the attributes are retained. I find the current behavior of the concatenation operator  (NOT retaining string attributes) to be at odds and inconsistent with LabVIEW. After all, it is a GRAPHICAL programming environment, is it not?

If I remember correctly, you also lose string formatting attributes when changing a string constant to a control or indicator - perhaps that also could use some thought...

[JÞB]

I'm not certain this is exactly the right implementation BUT, I like the concept.  it beats selecting and formatting text by index and selection.....

a better text editor might be preferable....  for display.

OK Stephen and I are apperently cross-posting.  it is too bad that Bold and <ERR> are the only keys down deep. 

It is true that a richer text editor ( or even UTF support) could be supported, but it would hamstring the string datatype.  Unless Stephen, or his R&D friends invest a lot of man hours(Years) in redefining some GObjects.  (Correct me if my assesment is off by orders of magnitude,  If you can do it easilly.......)

Again, I'm not certain this is the right implemntation... but the current display format options (WHILE effective!) are not user friendly.

[AristosQueue (NI)]

That would require a different data type than string. A string is nothing more than a stream of characters.

A string may be interpreted by a display. You are capable of creating, for example, an XControl that displays formatted text by embedding HTML tags in the string. You could also create your own version of the picture string for your own picture control. The data inside a string is whatever you interpret it to be. The formatting of a string display is not the same as the value of a string.

What you are asking for -- whether you intend to or not -- is for LabVIEW to create an entirely new data type which is something like "display string" -- just as we did with picture string. This string would somehow carry along with it data about formatting for a display. The two common methods are embedding control characters in the string or having a cluster of the string bundled with information about where to insert formatting. Regardless of which approach was taken, the various "string" primitives would then be taught to process this new data type... for easy example, Reverse String would have to be taught to know how to reverse all the formatting instructions also.

Alternatively, this new data type would have all of its own functions for manipulating it. I.e., Formatted String.lvclass would have a Concatenate.vi, Reverse.vi, etc.

But however it was implemented, it definitely would NOT be the LabVIEW string type, nor would it replace the LabVIEW string type... and it might not even be just a single Formatted String data type since there are many different standards for how to include formatting information with a string, HTML just being the most common.

> After all, it is a GRAPHICAL programming environment, is it not?

Although I appreciate the spirit of this comment, it is a bit off base. "A graphical environment for programming" is not the same as "a graphical environment for programming graphics". What you are asking for is a library of functionality specifically for manipulating formatted string data. It's something that LabVIEW could certainly develop, but it isn't as much a part of its core mission as your comment seems to imply.

Your idea is something that LabVIEW does not have today and for that is a good idea. It is related -- but not the same -- as this existing idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/HTML-Control/idi-p/1633360

The other idea only asks for an HTML rendering control/indicator, which is a much easier to request to fulfill than a full on formatted string data type. Yours is the more ambitious goal.

[AristosQueue (NI)]

By the way: The picture string is an example of formatting codes being embedded in the string. The internals of the General Error Handler.vi, where we translate the bold face tags <b></b> into an array of character indicies for starting and ending bold face, is an example of carrying the formatting information along with the string.

[johnsold]

AQ has stated clearly the distinction between the display on an indicator (and probably controls and constants) and the value of the data in the wire.

Would it make sense to add some property nodes which enable/simplify/mess up really badly the formatting of the indicator without touching the data?  I have not thought much about this or how it might be implented but this could provide some of the functionality of this request and of the HTML Control idea without requiring a full implementation of that idea.