How to access a combo box value by providing the selection string from another vi.

[nelg87]

Hi,

I have a lower level communication vi with a combo box.  I'm using the strings&values[] property to initialize the combo box.  When I select a string from the dropdown I get the corresponding value but when I pass in the same string from a caller vi I don't get the corresponding value.  How can I access the value for the item I'm selecting from outside??

[RavensFan]

Perhaps you should just use the strings & values property node to them out of the combo box, then search the 1-D array of clusters for the string that matches the one you are looking for, then return the corresponding value.  Since it sounds like you are trying to access the control programmatically, use the programmatic features that are available.

Maybe I'm mistaken in what you are trying to do, in which case please post some representative VI's.

[nelg87]

Thanks Ravens Fan,

I did what you suggested.  Looking at the text string property and searching the array for the correct value pair seems to work.  I thought there was an easier way to access the values directly but this works too.

[Rob_Calhoun]

Some LabView controls have special properties when used as user interface elements that they do not have when called as a subVI. For example, the numeric controls can be configured to restrict input to a certain range of values in the UI. However, for performance reasons those restrictions have no effect when the VI is called as a subroutine; it's just an unconstrained numeric input.

The combo box apparently falls into this category. When used in a user interface, a combo box gives the user a list of strings to choose from and returns the "value". If "value" isn't defined (frequently, since combo boxes allow arbitrary user input), it is set to "string". When used as a subVI, it behaves oddly. I set the following {string , value} pairs:

{apple, red};{grapefruit, yellow};{watermelon, green}

Behavior was as expected as a UI element; apple returns red, grapefruit yellow, watermelon green and kiwifruit (not on the list) returns kiwifruit. However, when called as a subVI, the combo box returns "string" even when there exists a match in string and value list. (For example, passing "apple" returns "apple".) It appears the special substitution behavior of the combo box only works when it is a UI element and not when it is acting as a string control.

Since this call-dependent behavior is evil, I'd recommend against using a combo box in this way. If all you need to do map a set of predefined string to a number, use an enum (if strings/values can be defined at compile time) or a ring (if strings/values must be defined at runtime.) A little known secret is that "Scan From String" will convert an (exact match) string to an enum if you wire the enum into "data type". A typedef'd enum is the safest string-number mapping, but is less flexible than other methods.

If you do need your subroutine to act on arbitrary text input, enum/ring is not the right choice. In this case separate the UI (which can have the combo box with "values" undefined) from the code that does the search/lookup/translation from "string" to "value". Use a regular string control for the latter.

-Rob

[nelg87]

What Rob described is exactly the behavior I was observing in my vi.  It is good to know this type of information since I'm an experience programmer but new to Labview and I'm not aware of this kind of behavior.  Also thanks for the enum tip.  It's kind of frustrating to know exactly what you want to do programatically but not know which control/function/subvi to use to achieve it. 

Anyways, for the purpose of my vi's functionality I don't think I can't use an enum since I need to specify custom values for my string labels.  My strings are basically a list of RS232 commands and my values are the corresponding hex raw data that I need to send through the com port.  So as you can see my values are not exactly numeric... I've already implemented a workaround as I indicated on my previous posting but I'm curious to know how will an experienced Labview programmer will handle this??

[Rob_Calhoun]

Here are some ways to do it (if I understood correctly what it is you want to do!)

I use enumerated types extensively because LabView makes it very easy to keep track of changes you need to make if you, for example, add an element to the enum. (Most of the time we don't allow default value for enumerated case statements.)

-Rob

[Seventeen17]

In addition, if you programatically select an item by its value (instead of by its text), reading the control then returns the value rather than the text.

In your example you could wire the string constant "red" to a local variable of the combobox in order to select "apple"...when you subsequently read the combobox (wired to an indicator OR via its property node "Value") it will now return "red" which is the value field.  The property node "Text.Text" still returns "apple" as expected.

With that being said, this "feature" of selecting via value obviously doesn't solve anything, but it's interesting none the less (what were they thinking?!).

[RavensFan]

You are responding to a 5 1/2 year old thread, and I have no clue as to what you are talking about.

You might want to put together a meaningful example that can explain what you are trying to say.

[Seventeen17]

My post was a response to Rob_Calhoun's first post on the thread (msg 4 of 7), and written in that context.  I didn't notice the age of the thread, sorry...perhaps the issue has been resolved in more recent versions of LabVIEW...I'm still using an older version.