simplify formatting of cluster elements into strings

[mikeporter]

My idea is to provide a mechanism by which a cluster can be wired to a single terminal of a Format to String function. The individual items could then be referred to by name in the formatting string - perhaps using a syntax similar to the current one for selecting the input to format by position number. It would not be hard to envision a syntax that would be able to handle arrays, and even embedded clusters.

For example, say the basic syntax for accessing a cluster item by name is something like:

   $item_name.format_code.

So formattinga value name "number" could be something like:

   $number.%d.

Extending this example to an array of numbers, contained in an item named "numbers", you could do something like:

   $numbers[%d"\n"]

Where each element in the array would be formatted into a number followed by a linefeed. Finally, you could support arrays of clusters with something like this (for an array of error clusters):

   $many_errors[{"Status ="$status.%b", Code ="$code.%d", Description ="$source.%s"\n"}]

To generate one line for each element in the array.

Mike...

[AristosQueue (NI)]

Speaking strictly as a LabVIEW user and not as a member of LV R&D:

I dislike this idea. You're moving information off of the diagram and into text blocks. If I wanted to decode cryptic strings and keep a mental parser running in my head, I would work in a language other than LabVIEW. I use LV because messes like that are kept to a bare minimum. Increasing their frequency by adding such features is counterproductive to me.

As a member of R&D, the syntax you've proposed would break any existing code that used a $ as the parser would say "Hm... I see a $ so I'm expecting a cluster type input". Also, you've got to specify which input index in the event that multiple clusters are wired to the same Format Into String or there are additional inputs other than the cluster (unless you're ruling out having multiple inputs when one is a cluster, but that would seem to limit more than free). You'll need to come up with a syntax that starts with a % at least and does some sort of escaping so that %status doesn't get interpreted as %s followed by the letters "atus". Probably something like %_ so that the underscore indicates a special parsing mode. This sort of thing is doable, but the devil is in the details.

Back to being a LV user -- and all that black parser magic just makes me dislike the idea even more. Your idea says this would simplify formatting... I strongly disagree. 🙂

[X.]

But AQ, I think you get the underlying message: LV to text tools (and back) are cumbersome at best.

There was an idea recently about allowing formatting to be added next to each wire terminal (in a Format String Node). I think Mike's idea could be rephrased into extending that to clusters (maybe some disclosure triangle could be used to expand or collapse the formatting of different cluster elements?).

I agree with your assessment that Mike's solution departs from graphical programming, but I agree with Mike that LabVIEW is not really user-friendly on his particular use case.

[AristosQueue (NI)]

I disagree. I think Unbundle is a preferable way to decide how to build up a string.

Honestly, I would remove the format strings from LV entirely. Just have a %% place holder for a string. There would be one and only one format for each data type. If you want a different format, drop a node that formats that format. So instead of using %d most of the time for integers and switching to %x for hex, %% would always be decimal string, and if you wanted hex, you would drop a To Hex String node prior to the Format Into String. The %% could be annotated with terminal indicies (i.e. "%1% is wired after %0%") in order to facilitate localization (translation into other human languages).  I would provide a default string represenation for compound types like arrays, clusters and objects. But if you wanted anything other than that, drop a subVI that builds up that string and then wire it into the Format Into String.

That's how string handling would work if I got the exclusive vote to design it. I don't get such a vote, so you don't have to worry, but that's the approach taken in some other programming languages and I find it to be a lot easier to read than magic incantation format strings.

[tst]

AQ, if that's what you want, maybe you should add an idea for it. If I saw a mockup for something like this which looked like something I would want, I might vote for it. Of course, I don't know if that's relevant now that there's a lot of legacy code around.

[AristosQueue (NI)]

Tst: I don't want it so much that I'm willing to expend even one iota of developer energy to get it. There are so many things I would put ahead of that idea, personally, that I wouldn't add it to the exchange on the off chance that the rest of you might vote it up. 😉

[mikeporter]

Well, the fact of the matter guys is that whether you like it or not, LV does have to sometimes assemble strings - and it already provides a mechanism for manipulating where the formatter gets data. My idea simple expands on that logic. And yes you are moving information into a text block: The information on how to build the text block you're building!

If I am assembling a block of text that I am inserting a dozen or so strings into, I would much rather read the name of the value associated with item 6, than count down inputs to see what is wired to item 6.

Mike...

[mikeporter]

PS: about removing the format string entirely, that's the way LV used to be -- in Version 1. Now that was a pain...

[AristosQueue (NI)]

Mike: But when someone changes the name of the element in the cluster, the Unbundle By Name solution will stay up-to-date through many kinds of name changes, whereas the text embedded in the string will simply be a runtime error that may take a long time to track down. Now, if you have a *static* string to format into, we might be able to do something like this:

The wire goes into the position where that value will be displayed. But that only works for static strings, not dynamic strings, which breaks the localization use case when trying to create display strings (which for me is the 90% use for this node).

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.