Add boolean text specifier in format into string

[JimChretz]

I wish there was a boolean text specifier for Format into String functions.

% followed by "?" would expect two possible strings like this. Why not?

[crossrulz]

We would probably want the true and false strings to be in quotes.  Otherwise, it looks pretty much just like TestStand syntax.

Locals.String = Locals.Pass?"Pass":"Fail"

[wiebe@CARYA]

I get "%?(pass:fail)s" is based on C syntax, but it seems a bit random considering the other formatting strings. 

I think we can all agree on the %. 😁

Why the question mark? For a timestamp, a more detailed specifier is: %<>T. I'd rather see a Boolean specification look like that. You can put text in there, and it's not quoted.

Why the "s"? This letter specifies how the input should be interpreted. All outputs are string, but it specifies the input. An enum can be %s, but then it is actually interpreted as a string (e.g. it has strings). b would be more logical.

Something like:

%<true:false>b

Although a : might not be the best choice.

---

@JimChretz wrote:

Why not?

---

I'm sure it will ruin some code.

Every now and then you need to parse\modify format strings at runtime (from user input). Code that does this would need to be revised.

It might be worth the trouble. A reserved +1 for me...

[JimChretz]

Currently it already returns "TRUE:FALSE" using %s bor boolean input. That's why that "s" would make sense.

I thought of %b but that letter is already used for binary integer, it would return 0:1 with a boolean.

I agree with your %<Pass:Fail>s suggestion, but with the "s", not the "b". 🙂

[srlm]

I am deeply unfond of putting logic into an embedded syntax language. One objection is just more hiding and obfusication of logic. But the other is that features like this (encoding a downstring string into a control string) inevitably require escape codes and additional syntax that become yet another source of programming error. 

I would prefer that this feature never become part of the language so that I do not have to update our style guides to forbid using it.

[srlm]

>  but with the "s", not the "b".

If LabVIEW is going to do this feature, then It has to be a "b". An "s" indicates that any string or type that can be interpreted as a string could be wired to the terminal and be accepted. Format codes are supposed to be universal to the type being formatted. Since this format code only applies to booleans, it should be a "b" to indicate the limitations of acceptable types. (Whether or not the terminal accepts integers that could be interpreted as "x != 0 => true" is a separate question.) 

[Darren]

I prefer the readability of this:

...or the Select code wrapped in an inline subVI with a good icon.

[wiebe@CARYA]

---

@JimChretz wrote:

I wish there was a boolean text specifier for Format into String functions.

% followed by "?" would expect two possible strings like this. Why not?

---

That wouldn't work when the format string is user editable though:

It's a corner case but will eat up your time budget when you need it.

[srlm]

> That wouldn't work when the format string is user editable though:

That's another reason why it has to be %b, so that the Format Into String can return a useful error message. 

[wiebe@CARYA]

>> That wouldn't work when the format string is user editable though:

>That's another reason why it has to be %b, so that the Format Into String can return a useful error message. 

But %s wouldn't result in an error? I'd say it's better if it just worked with %s that return a useful error with %b?

[srlm]

%s is a promise that this works with string types. This format cannot work with a string type as the input. It doesn't make any sense to have an error message that says that "%s cannot accept a string type" -- it by definition must be able to accept a string type. But an error message "%b cannot accept a string type" does make sense.