Fix bug: "Change to Control" should obey "Connector pane terminals default to Required" setting

[Petru_Tarabuta]

Bug replication steps:

• Ensure that the "Connector pane terminals default to Required" option is ticked (found in Tools >> Options >> Front Panel).
• Connect an indicator to a VI's connector pane.
• Right-click the indicator and select "Change to Control".
• The indicator changes to a control, but the connector pane terminal is Recommended. It should be Required (should obey the environment setting).

Notes

• Mis-connecting an indicator to the connector pane while believing it is a control can occur moderately frequently, especially when working with front panel elements that do not look very different when they are controls vs. indicators, for example: variants, objects, typedef clusters, system-style strings or paths.

[_carl]

This exact issue drive me crazy for years, and took quite a while for me to eventually realize why these controls weren't marked as required...

Seems like it'd be a pretty easy fix to roll out.

[fefepeto_kb]

It might be a corner case, but if the indicator is a dynamic dispatch output on the connector pane, I would prefer to convert that to a dynamic dispatch input.

With that said I think we shall have multiple use cases which might seam inconsistent at first:

• Dynamic dispatch output -> dynamic dispatch input
• Recommended output ->
  • Required input if default in the settings
  • Recommended input if required is not set in the settings as default
• Optional output -> Optional input

And to ensure consistency we have to define the other direction as well:

• Dynamic dispatch input -> Dynamic dispatch output
• Recommended input -> recommended output
• Required input -> recommended output
• Optional input -> Optional output

If we take a look at the bold cases above, then it becomes obvious where the problem might be. If I had a recommended input, while the default settings where required, converted into an output, then converted back to input it becomes required, and potentially makes a lot of subVIs broken for no reason.

Again, this might just be another corner case, but adding new inputs to a VI will always cause broken callers if the input is required, and no broken callers if the input is recommended. The only caveat is, that it provides no information when the VI is brand new and not called anywhere.

I think the ideal solution would be an improved connector panel experience. Like a new dialog comes up alongside the front panel, and allows the users to move the connectors around easily, to convert the controls to indicators and vice-versa from the new dialog. Cycling trough the required, recommended etc. setting on single left click. This would simplify the VI interface editing and also improve the productivity. The downside is a lot more effort.

[Taggart]

@fefepeto_kb

Thanks for taking the time to think through that. I see the issue you are raising. It could potentially cause a problem and it seems to me that the existing behaviour causes more problems than the issue you are raising, so on the whole I would say the trade is worth it (at least for me).

[_carl]

@fefepeto_kb wrote:

If I had a recommended input, while the default settings where required, converted into an output, then converted back to input it becomes required, and potentially makes a lot of subVIs broken for no reason.

Personally, I have no expectation that if I change a control to an indicator and then back to a control that this control matches the initial control settings.  For one, it's an extremely rare scenario.  For another, there isn't a 1:1 given that indicators can't be required.

I have LabVIEW configured to default inputs to required (and anyone on this forum should too -- still a mystery to me as to why this isn't the default setting in LabVIEW, but that's a discussion for somewhere else). As such, I expect that any control I create starts off as required, regardless of how I create that control. For me, it's important to avoid errors that result from not wiring up an input. And I find the current "change to control" behavior to be dangerous because it unexpectedly bypasses this safety check.

---

[_carl]

One more comment on this.

This most-commonly happens to me when I'm adding a boolean input. "Round LED" is my preferred control, and it gets dropped as an indicator from the palette. So I have to perform two steps after dropping it from the palette: change it to a control, and attach it to the connector pane. If I choose the wrong order for these seemingly unrelated operations, then it ends up being recommended and not required.

Not ideal.

[fefepeto_kb]

This most-commonly happens to me when I'm adding a boolean input. "Round LED" is my preferred control, and it gets dropped as an indicator from the palette. 

I agree with the required controls options shall be the default in LabVIEW, however using Round LED as control is in general a bad idea. This type of indicator is for user facing UIs for the most part and since the colors on this control can be changed it might result in inconsistency especially when working in team (someone might prefer the off and on colors swapped and confusion is granted).

Anyway, it's off topic, but there is a good reason for controls being controls and indicators being indicators on the palette.

Regarding the Control->Indicator->Control use case: Thinking of a control queue, the data input shall always be a variant and recommended. If the control has been changed to indicator accidentally, there is no clue on the front panel, only in the hint window or calling VIs that wired that input. But you might also changed other things in that VI, so now you want an easy way to go back, but undo is not an option. So you just quickly convert it back to variant, and don't expect it to become required right away.

Because of cases like this, I would prefer a proper UI for the connector pane edits, just like the Icon Editor for icons. The connector pane is too small on the FP window to properly display information about the status of the connectors, like different hatches for required, dynamic dispatch, recommended and optional. And maybe a different outline color for controls and indicators. While its more effort, it would be really practical and way more effective.