Show the default value of controls in subVIs which aren't required in the tip strip

[tst]

Earlier, I posted this idea, suggesting that the error in control should not have the default value in parentheses.

Following another discussion, I now suggest an extension of that concept - No control should have the default value in parentheses. This clutters up the front panel and the diagram of the subVI.

Instead, when you hover over the input of a subVI, LabVIEW should look at it and if it's not required, should add the default value to the tip strip automatically:

 

This change will require us to modify all our old code if we don't want to have the clutter, but I can personally live with that. Alternatively, LV can try to be clever and do something like: "If the control isn't required and has parentheses at the end, don't display the default value".

[RandyP]

(continuing on my above comment)

Hmm... and maybe there also should be an option to be reminded to update the DVD (Default Value Description) when the default value is changed if the DVD is user-defined (AKA a U-DDVD :-p). ...or maybe I'm just getting carried away....

[Henrik_Volkers]

I also vote for Context Help to show the default value.

Usercase clustosaurus: Show it as a picture? XML style? Only as picture if stricly typedefed?  Diagrams, picture controls, picture rings .... 

[tst]

Allow me to clarify.

The default value isn't useful on its own. It's only useful under very specific circumstances:

1. You have a non-required input         AND

2. The input has nothing wired into it   AND

3. You're on the BD of the calling VI and want to see what the value is.

Most of my inputs are probably required. Certainly complex ones like clusters, so I don't think there's a need to show the default for anything that can't be flattened simply into a string. The same goes for long strings. If your inputs have very long strings, you deserve to be punished.

Then, you have "defaults" which require explanation (such as a null VI ref which means "this VI" or an empty path which means "show file dialog"). In these cases, you can simply add the explanation to the label just as you did until now.

I mentioned in the idea that it would be possible not to display the default if the label had some characteristics (such as parentheses at the end or a special char or a control property which says "don't show default value").

I don't have a problem with the info appearing in the CH window, but I also like that it appears in the tip strip. I find it very useful. Also, remember that if the feature is too complicated, NI is less likely to actually implement it. Keep it simple.

[jmorris]

So, the goal here is to reduce name sizes on the BD and front panel, while still showing the default value when it is useful.  I agree this would definitely be an improvement.

I like the idea to have LabVIEW automatically append the default value to the name when appropriate.  That means only non-required inputs, on both the tip strip and context help.  I don't think it should hide the default value when something is wired there, because you shouldn't have to delete the wire to easily find out what the value would be if you deleted the wire.  😉

I believe it should be very rarely the case where the default value being appended to the name would make the tip strip / context help display awkwardly long.  For those times, a checkbox in the properties of the control to turn off display of the default value would be available.  I think the default should definitely be to display it, though.

Having LabVIEW do this has the additional benefits of both saving time because we don't have to do it ourselves, making sure we don't forget to do so, and encouraging / showing the good style standard to new programmers.  I like it!  🙂 

[Roy_F]

I prefer there not be an option to globally disable the auto-display of default; showing the default for optional or recommended inputs when programming has real value and the developer should not be able to ignore this, even if they (think) they want to (that'll ruffle some feathers).

We can inhibit appending the default for required inputs - serves no value there.

We could inhibit this for labels or captions that already have something within parentesis, assuming the developer has already provided his own default indication (existing code would not need to be touched).

Clusters don't make sense - ignore those.

Long strings could be truncated with ... appended.Tool tip could use a longer length than CH.

[tst]

> We could inhibit this for labels or captions that already have something within parentesis, assuming the developer has already provided his own default indication (existing code would not need to be touched)

Not needing to change existing code and the option to include an alternative description (such as "browse for path" for an empty path input) are the main reasons I brought this issue up at the end of the idea.

There is one problem with this, however - units*. I tend to include units in parentheses where applicable, so that would break that use case. I assume that some people even have a format of having the units and the default value included in the same pair of parentheses. For these cases, having a "don't show value" property for each control is probably better, or at least clearer. It will mean that old code would need to be fixed manually over time.

* Yes, I know LV has the ability to use embedded units. This is not what the discussion is about. I think we can assume many people have existing code which uses a similar convention (although that assumption is more of a guess).

[smmarlow]

Kudos to this idea.  As for those who commented about long data types, yes it would probably be restricted to scalars, and other 'short' data types, and long strings could be partially shown with a '...' at the end indicating more characters following, etc.

[LabBEAN]

<<tst wrote:  I assume that some people even have a format of having the units and the default value included in the same pair of parentheses.>>

Yes, for subVIs, I am one of these [e.g. Length (2 ft)].  This case would be treated exactly like Length (2), where NI would not display the default value.  For those who have included only units in ( ), they are no worse off than today.  Moving forward these folks will learn to include units in [ ] or { } instead.  The context here is subVIs, so designators like ( ) or [ ] become semantics.  Don't see a reason for NI to delay the implementation for this corner case.

Because CH (Context Help) can get bloated (and spontaneously change sizes), even with dual screens I hide it most of the time.  I like the "..." idea to limit descrption length in CH [e.g. "String 1 (Ridiculously long default value either justified or unjustified for String 1 string control)"].

-Shalom