Connector Pane Terminals Default to Required instead of Recommended

[Chris V]

From my experience, it would be more useful for terminals on the connector pane to default to Required instead of Recommended.

Here's my thinking:

• Usually You Want It - In general, when you create a SubVI you require all of the inputs, in which case it is a pain to go and change every terminal individually to required.
• Conscience Programming - If you are creating inputs for your SubVI that are not required, chances are you are very conscience of this, have done it intentionally, and written code to handle that case where the terminal is not wired.
• Easier Debugging - If Required terminals are not wired, VIs will be broken, i.e. you have compile errors instead of run-time errors.  These are much easier to debug (especially when the errors appear on functions inside your SubVI that did not receive their required inputs).  If in fact the terminal should not be required you are prompted to make that decision, instead of finding at run-time that your program does not work as expected.

I completely understand why we need these three categories.  However, it seems that the usual use-case is and should be Required and therefore the default should refelct this.

Chris V

[Samuel_S]

I would agree with Chris on this and would like to see this implemented

[BTreece]

Another benefit is for large applications.  When a terminal is required default data is not required and therefore memory usage can be reduced.

[tst]

Just to make it clear - the options dialog already has an option for having terminals default to required. The idea should be about changing the default value of that option.

[Chris V]

@tst Yes, that is correct. (For those who don't know, Tools>Options>Front Panel).

But yes, I think the default for that option should be true.

[jlokanis]

I like this idea, but with a slightly different option.  I would like to still have most terminals default to recommended but all terminals with any kind of reference attached to them would default to required.  I find that in many cases I want to have an input not be required so I can use the default value in most cases.  But I think it would be very rare to write a VI with a reference input that you would not want to always wire.  This has bit me more than once over the years.

[Brandyn]

THIS IS TOTALLY AWESOME!!!!!!

[Verywiseguy]

I'm curious, is there an argument against this being a good idea? Besides the obvious concerns of suddenly changing a default option convention for every LabVIEW user in a new version.  I'm just wondering if there is any good reason why I shouldn't check this box in the options. Chris V kind of drives home the idea that inputs defaulting to required is safer and more convenient for most users and should be the default option.

The way it is now, it seems like the following could be a pretty typical LabVIEW user experience (as it was just my experience).

1. New LabVIEW user doesn't really pay attention to the subtlety of switching all of the sub-vi inputs to required.  They just wire everything up.
2. Over time, new LabVIEW user grows in experience.  One day they accidentally unwire a terminal of a sub vi.  
3. They spend a while trying to figure out why their program is giving them garbage all of the sudden.
4. After a while they find the unwired terminal.
5. They fix it, discover this setting, and check the box so that a broken arrow will prevent this issue from happening again.

While this was a useful learning experience that has taught me the importance of making sure require inputs are required, wouldn't it be better that the default option is the one that prevents errors, rather than setting people up for a trial by fire learning experience when something finally/inevitably goes wrong?

I'd be interested to hear a reason against this, in case it is something that should make me reconsider changing the setting, but for now Kudos from a growing newbie.

[tst]

I can't think of a good reason. I suppose there are some users who want many inputs to be optional (see jlokanis above as an example), but I expect these are the exception rather than the rule and I fully agree with your reasoning about the safer choice for beginners. I'm guessing the reason this wasn't changed is more lack of awareness or that no one was working on that area rather than an actual decision to not do this.

There is at least some awareness of it, though, so maybe it will happen at some point. See here - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Get-rid-of-number-on-default-icon/idc-p/2701621#M26327

[AristosQueue (NI)]

There is a Tools >> Options setting to make LabVIEW do exactly this.

Tools >> Options >> Front Panel >> Connector pane terminals default to Required

It is not turned on by default. The argument (and let me say that I do not personally agree with this, but it is the prevailing theory on LV R&D) is that new users become extremely panicky when they do something right but see a broken run arrow. Apparently, it is a problem in various test groups. So there's a great deal of pushback against anything that increases the number of things that create a broken run arrow if the action is a good action. This is one reason why, for example, the Event Structure drops with a "Timeout" case already set up instead of dropping with an empty frame that you have to configure.

Personally, I prefer to use the error list as my todo list and I like when compilers break things to keep me from forgetting operations. So I use the Tools >> Options setting.

I (and others) continue to campaign to change the default for this setting. No success thus far.

[Verywiseguy]

Thanks for the response.  I have recently become aware of the setting, I just wanted to make sure there wasn't a dangerous downside to it that I wasn't aware of. There's usually a good reason for things being the way they are, and there wasn't a solid reason against this idea in this thread. That argument about not wanting to provide unnecessary negative feedback to new users at least makes some sense.

Still, I would have much rather found my mistake via a broken arrow than from the little adventure I had to go on. Like eating vegetables and doing your homework, there are some things that wiser people should insist the young learn to deal with because it's good for them. I'd say learning to utilize the broken arrow is one of them. I understand the argument about "doing things right but seeing the broken arrow," but I hardly think throwing a function on the BD and not wiring it up properly could be considered doing things right.  Any basic function on the pallettes with a required input will break the arrow in the same way, why not mine?  I would be surprised to learn that new users are creating sub vis with the express intent of having more recommended terminals than required terminals (though I admittedly have no data besides my own history).

But I suppose I'm preaching to the choir on this one. If nothing else, take me as an example where the current setting directly led to some frustration, where a broken arrow would have taught me to be more careful months ago. Keep up the good fight.