Add "Exclusions" Option for "Connector pane terminals default to Required"

[FireFist-Redhawk]

I initially came here to suggest that there should be an exclusion added for error terminals when selecting the option in Tools > Options... > Front Panel. But then I thought, why not just let us configure which data types default to required and which default to recommended. I'm probably being nit picky here, but I think this would be a really cool thing to add.

Check the box, then a nested list underneath, where you can add exclusions, becomes un-grayed out. Data types you don't want to default to required.

[AristosQueue (NI)]

1. Error terminals are already excluded, and have been since the first release of this feature.

2. I created this particular option. When I did, I examined all of the type usages I could find.

2a. Of the seventeen (at the time... nineteen today) fundamental LV data types, none of those ever get used majority as optional inputs... indeed, all the other types are generally better as required (we can get into a larger discussion about whether "default to Required" should be enabled by default... personally, I think it would help LV users considerably, but I lack the data to formally propose the change).

2b. So that means the only types that might want this kind of exclusion are the user-written types: typedefs and classes. If we were going to add the exclusion, it would be easier and more obvious to add the option to the properties of the typedef or class because that would make it universal on all machines for all people using that type -- it would properly be part of the type definition. I've kept my eyes out for any typedef or class over the years that wants that exclusion, and, thus far, I've seen none. If you have an example of one, I'm very interested to hear about it.

2c. There is an interesting corner case I've seen of a "settings" class that in some applications initially wants to be required for all VIs inside of the class itself and recommended on all VIs that use the class, but I've never seen an example of such settings classes that didn't end up becoming Required on at least some external APIs, thus tipping the balance over time.

3. All of the above begs the question: what makes the error cluster so special? Well, as I've noted in many presentations in recent years, errors are or become special in every programming language we can look at. Error is the only type that appears in all APIs and joins across APIs. It becomes a ubiquitous part of every non-trivial application. Therefore most languages and/or programming environments develop either a library or a language specialness around the error handling. In light of that, it is unsurprising to me that it is the one type that needed to be excluded from the general "assume all inputs are required" setting.

4. Long and short of it: I don't see a need for this idea's proposed change, but I'm open to discussion if you have examples.

[FireFist-Redhawk]

Thanks for the quick reply.

Well, my first response to that is... I feel pretty stupid right now. I only thought of this in response to wanting error terminals excluded from this option, which they already are. Then I just generalized the idea so to speak and posted. The only other data type I personally consider as not normally being required is boolean inputs. They are almost always options that can just have a default value if not wired (unless those are excluded too).

My second response, is that there should be some affordance to the user that error terminals are indeed excluded from this option. It seems to me that the only way to know this is the case is to be told by someone else, as this fact is nowhere in the detailed help for the option.

I would have been using it all this time if I had known! 😅

[AristosQueue (NI)]

> It seems to me that the only way to know this is the case is to be

> told by someone else, as this fact is nowhere in the detailed help

> for the option.

I swear it was in the documentation at some point. I will file the bug report now.