Too FEW format specifiers should not be an error for Format Into String

[Darin.K]

I am a fan of the Combo Box for situations when I have a set of not-so-human-readable strings I would like to map to their human-readable counterparts in a clean and extensible fashion.  So far, so good.  Often, however, those illegible strings are also format strings which I often use in combination with Format Into String as below.

The problem, however, is when the different commands use different numbers of inputs.  It is no problem to always wire input 1 and input 2, it is usually obvious from context, or through visibility controls which ones correspond to different commands.  The problem however is that when I only use one format specifier in the format string the Format Into String function throws an error and returns an empty string.  Too many specifiers is one thing, but in my opinion, too few should not be an error.  A warning, maybe, but I'd ignore that anyway.  Or, if an error must be thrown, at least return the result with the subset of inputs used.

One workaround is to use a case structure to sort by the number of parameters to wire.  Not horrible, but the cases are based on the not-so-readable strings.

[shb]

I suggest to throw an error as today but to return a string with as many specifiers filled in as specifiers exist. Or add an option to the function which enables to provide to few format specifiers.

[pauldavey]

You can get the desired behaviour by using the $ for changing the order of the specifiers.  In your example, if the format string was "%2$f" then there would be no error, and you would simply get the second argument formatted in the string.

Help for Format into String function

[pauldavey]

You can get the desired behaviour by using the $ for changing the order of the specifiers.  In your example, if the format string was "%2$f" then there would be no error, and you would simply get the second argument formatted in the string.

Help for Format into String function

[AristosQueue (NI)]

Kudos to the idea for highlighting a problem, although I'm not a fan of the proposed solution nor the variations proposed thus far.

> I suggest to throw an error as today but to return a string with as many specifiers filled in as specifiers exist.

While that might be good on this one node, I observe that when a function returns an error, the outputs should only be pass-through terminals or default-default values. Having individual nodes that violate this rule just leads to harder-to-find bugs and worries about error handling ("do I need to do something special in this node? how about this node?") LV has very few such nodes and none in any modern API (meaning last 10 years) that I've seen. It just seems bad to break that overall paradigm no matter how good it seems for an individual node.

I'd suggest an additional input on this node for "ignore error if too few specifiers". I think it is good that we default to return an error in this case -- ideally, string specifiers and terminal count would be compiler-checkable, but that's imposible, but in most cases, if a programmer wires a value, they expect it to be included in the string. So having a way to expressly say "I intend to provide a shorter string" seems like the right balance, to me, between having the error and being able to acknowledge the less-common situation.