Add dropdownlist style option to LabVIEW combo boxes

[Mads]

If we want a ring of a string type we can use a combo box and if undefined items are not to be allowed it *could* behave as a regular ring (integer type) with no text editing/input, but that is not an option in LabVIEW now. Having such an option would allow us the keep the behaviour of multiple ring controls identical (and hence more intuitive to the users) although their types behind the scene for programmatic convenience are different.

If you want to keep the ring as a string (to not have to deal with it indirectly though the ring/enum string array property, which would be the current workaround...) you are currently forced to accept that the this ring will behave differently than other ring controls or enums:

In Microsoft applications the suggested feature is available by setting the style of the combo box to DropDropDownList.

[Mads]

A related discussion:

https://forums.ni.com/t5/LabVIEW/Force-a-combo-box-to-only-work-as-a-drop-down/td-p/4439279

[Yamaeda]

I agree, either a separate option, or automatic when not allowing undefined strings. No, then you can't click and search ... New option it is.

[mcduff]

Besides the dropdown feature, I would like the following also: 

No need to highlight the text,

Add a check mark in the dropdown box for the current value

[Jim_Kring]

I can see how this would be useful. One consideration is that, if the data type is a string, then it must be allowed to have any possible string value at runtime. This means that it must be possible to set its value to any possible string, since local variables do not have error outputs to handle a case where and undefined value is passed in. As such the combo box on the front panel would have to at least display undefined values, even if the user is not allowed to enter them. This is probably acceptable for your front panel user interface needs. Yet, I figured I would mention it.

[Mads]

The need to support display of any value because you can force it to such through a local variable is a corner case yes...and the best formal solution would be for the control to refuse the value if undefined values are not allowed, but then that should ideally require locals to have error outputs (perhaps even inputs, for flow control 🤔 ). A simpler solution would be for it just to display the programmatically accepted string as you mention.

This touches slightly on a different aspect of undefined values in general by the way; how amateurish-looking the input has been implemented on ring controls in general....A separate idea about that can be found here:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Allow-Undefined-Values-quot-interface-refinement...