An altermative to the "Format into string" tool.

[oyester]

Format into text is very useful but can become hard to edit when it has a lot of inputs. I propose, instead of one huge format string, that the programmer be allowed to put the required format next to the corresponding input. Also, the user should be allowed to enter constant strings, e.g.. \n, \t, or "Comment", and have the corresponding input field automatically grayed out.

[tst]

I'm a bit torn about this, because while I agree that there's a problem here which needs to be solved (how to easily match between the format string and the terminals on the node), this suggestion solves that problem, but makes the string harder to read. This could possibly be handled by adding an optional display/editing string, because reading or editing the string can be easier than reading a vertical set of terms.

That said, this still doesn't offer a significant advantage over the existing graphical editor (right click >> Edit Format String) other than allowing you to see at wire time exactly which argument you're working on, but that only helps to a degree, because the string is still hard to read.

An alternative implementation to aid with this problem would be that when you hover an input terminal for the format primitive, LV will highlight the relevant section in the string and vice versa, but that might be more difficult, because it would require a different behavior for that string constants and because sometimes you don't even have a constant. Maybe this could be applied to a string which is part of the node.

[GregR]

One of the issues I have with the current dialog is what I consider inconsistent treatment of spaces. The format "%f %s" and the format "%f%s" show up the same in the listbox of the dialog but they are clearly not the same thing. If you escape the space ("%f\s%s"), then the listbox shows 3 elements. For most cases I never want to see "Output exact string" in the listbox because it only obscures the format strings I really care about.

I think the node you drew has a little bit of the same problem. If I want a space between 2 format strings, does that require an extra entry like your "\n"s. The space can't be assumed because I might not want it at all. I think each entry in a node like this should be treated like the string to the "Format Value" node. Each entry can contain any amount of static content, but only one % code. The original example would then only need 4 entries instead of 7 ("\n%s", "%^.3e\n", "%s", " %d\n"). For a string that is almost all % codes, this is not a huge difference. For a string that contains more static content, it could make it easier to read. The user can even decide how to split the static content between the % codes to make it the most readable. ("Pump #%d needs attention. ", "Motor temperature is %f C.")

Another issue is that this approach would not support the $ modifier for reordering inputs. This is most useful with localization where the format string is dynamic anyway so it just means this wouldn't replace a solution for dynamic formats.

[fabric]

Kudos for an interesting idea, but I would definitely prefer GregR's variation that groups the static content with the relevant variables. A possible extension of that idea would be to allow fields in the node to be switched on/off at runtime, eg a mechanism to only display "Pump #%d needs attention" when it actually needs attention. Not sure how this could be achieved whilst retaining a simple UI, but a right-click option to "ignore field on null/zero input" might do the trick... Just my 2 cents!

[oyester]

This suggestion was prompted by this mess

That eventually became this mess

It took some  time and a bit of stress to figure out what went where and I began to wonder if there was a better way to solve this problem. My suggestion was what I came up with. I see now that my initial concern was narrow minded and that there are several other issues involved here. I still maintain that my suggestion is a good starting point.

[RavensFan]

One thing that would help is to not have string inputs for the tab and EOL constants and just add that to the format string.  Then you are left with about 1/3 of the inputs, the only ones that truly change.  It doesn't make the format string any prettier, but it does take up a lot less screen real estate.

[Zafer.Depe]

I think, this idea is not a better solution nor an alternative to "Format Into String" function. Even this new tool seems strict and less flexible, I think a new function like this should be somehow usable as a new "Concatenate Strings" (Concatenate Anything). You enter a former string as an input then add some values (str,bool,num,..) and you get a concatenated values string. If, I am true kudos for the post.

[oyester]

If I understand you, Ravens Fan, you mean something like this.

[RavensFan]

I was talking about your example as far as how you have to do things now.  But sure, it can certainly apply to what you want to change things to.