Force a combo box to only work as a drop down

[Mads]

If you have a regular ring or enum, clicking on one of the items in the list (not the handle) will present the list of available options / drop down as a menu. However, if you really want this control to have a string type the only option (at least as far as I know) is to use a combo box.  The problem with this replacement is that it changes the navigational behaviour: Now you have to click the handle to get the drop down, clicking the text will give you an edit/search string cursor.

Yes, you can prevent people from entering *undefined* strings by setting the Allow undefined strings property to false, *but* the user will still not be able to click on the text area and get the menu of available string. That gets you a cursor. In order to pull down the menu, the combo box requires you to hit the handle instead.

This can be a bit confusing if the said control is in a mix of regular ring controls where clicking any area of the control will present you with the drop down menu, and it does not fit very well if the input texts are long and/or few (not suitable for search).  In other langauges you can set the combo box to fucntion asa drop down only...(here's looking at you LabVIEW Idea Exchange...)

I have a case where it for various reason would be much more convenient to keep this as a string type, but the combo box edit behaviour is unwanted. Has anyone solved this in a somewhat elegant way (that keeps the ring type a string, not an integer/enum)? An XControl perhaps (although that has its own quirks...)?

[altenbach]

You can always get the strings from the value, e.g. as follows.

You can even do short strings for the enum and a matching array of longer strings to index into (or vice versa).

[Yamaeda]

[Mads]

Sorry guys... I considered adding a more embellsihed disclaimer to point out that I know I can use enums or regular ring controls and access their string value etc, working around the issue, as you describe,..but the issue at hand is if the control *has* to be a string. 😮

[altenbach]

Oh, I was aware that you are an expert!

I did not quite understand the question. Any front panel string is cosmetic and the users would not really be able to tell the difference between strings of a combobox or strings of an enum/ring. That distinction really resides only on the diagram.

Maybe you could do a "mouse-down?" filtering event and pop something up?

[tst]

One thing that you can do (at least with some of the control types) is go into the control editor and into Customize mode and then move the drop down button over the text, bring it to the top and make it transparent. That will prevent the user from clicking on the text and will instead cause the dropdown to appear. If you still want the drop down button to be visible on the side, you could add a decoration, another combo box hidden behind the current one, etc.

A couple of caveats that come to mind:

1. I haven't made allowance for resizing etc.
2. I expect the user will still be able to tab into the text part of the control.

Another option is do what the others suggested and wrap it in an XControl, which entails all that comes with that, but can preserve the string type.

[paul_a_cardinale]

---

@Mads wrote:

Sorry guys... I considered adding a more embellsihed disclaimer to point out that I know I can use enums or regular ring controls and access their string value etc, working around the issue, as you describe,..but the issue at hand is if the control *has* to be a string. 😮

---

I'm interested to know why it "*has* to be a string."

[Mads]

Absolutes have a tendency to trigger the engineering mind, has it not? 😉

Short answer: The use case is to avoid having to include conversion when we could have a ring control of string type that works as ring controls of other types...

The case that made me post the question right now though? That case is more of a distraction here: It involves initializing the value of hundreds of individual controls in a GUI from some source clusters (why not use the clusters in the GUI you might say..) by label name instead of by wiring...(more flexible, dynamic and with less clutter). This is currently achieved with very little and generic code, but it does not handle a difference in type between the individual controls and their cluster counterpart. Inserting conversion code for some controls will be less convenient and elegant.). In this particular case I happen to control the cluster types *and* the GUI so I can always choose to just change the clusters or add conversion in the GUI...So there is a clear and not too cumbersome solution, but one that I would not even need if combo boxes could be set to act like other ring controls / disable their search/autofill feature...

[Yamaeda]

Disable the control, then it pops the drop down if you click on the text part. Works on text ring, but not Combo box. On Menu ring it works automatically.

[Mads]

Disabled ring controls do not show the drop down on my system...(I would not expect them to either). If it had worked it would still have to work on combo boxes to solve the issue...