Auto-populating of Case structure by Combo box

[mrkvolf]

Hello,

I miss auto-populating of Case structure by Combo box. What about you?

It works for Enum or Ring. But not Enum.

[tst]

---

@vom wrote:

It works for Enum or Ring. But not Enum.

---

Actually, it doesn't work for a ring. The reason it works for an enum is a fundemental difference between the enum and the other two - in an enum, the strings and values are a closed list defined at edit time and are part of the data type of the wire, so the editor knows about all of them. In rings and combo boxes, the strings and values can be modified at run time and don't actually exist on the wire.

Technically, LV probably could include a feature where there's an option on the case structure which follows the wire back to its original source and takes the current values from there, but I can't say I miss this too much.

[mrkvolf]

I've tested it.

In fact, Ring works a little bit better than Combo Box, but not as Enum:

• no "Add Case for Every Value" as Enum
• but something happens if you connect it to Case Selector of Case Structure

[crossrulz]

I think your definitions are a little messed up here.  The "Add Case for Every Value" is only available for the Enum.  As Tst already stated, the Enum has its strings and value (numeric) closely tied together at edit time.  This cannot be changed at run time.  The Combo Box is a string data type whose available values can change at run time.  The ring is a numberic version of the combo box..

[mrkvolf]

Please respect, that I'm solving only User Interface feature request.

Why to solve which object uses what data type??? "How-to" or "why it's not possible now" is not on the agenda.

On the agenda is, if you would like/dislike these new features:

• Issue: "Add Case for Every Value" is only available for the Enum.
  Solution: It should be available for Ring and Combo Box.

• Issue: Combo Box is not able to distribute its values to Case structure automatically immediatelly after connection of wire to Case Selector of Case Structure   (as Enum and Ring can)
  Solution: Add this feature to Combo Box

Reproduce issue:

1) Create Case structure + Ring, Enum and Combo Box control with some values

2) Play with reconnecting all 3 Controls to Case Selector of Case Structure

[crossrulz]

The solution is to simply use an Enum.  At the fundamental core level, that is what it was designed for.

[mrkvolf]

So Ring and Combo Box is not designed for connecting Case Structures?

[crossrulz]

Not in the fashion you are describing.  For the Ring and Combo Boxes, you need to give ranges and/or have a Default case.  They are variable in their possible values so we have no clue what values you will be passing to it.  With the Enum, we know what all of the possible cases are, so we can do a "Add Case for Every Value".

[tst]

---

@vom wrote:

• Issue: "Add Case for Every Value" is only available for the Enum.
  Solution: It should be available for Ring and Combo Box.

---

Like I said, NI probably could add the feature that takes all the current values from whatever is connected to the selector, but I personally don't feel the need for it that much.

[AristosQueue (NI)]

vom: crussrulz and tst are correct in their explanations. What you are requesting is an impossible request in its simplest form, and one that would be a bad idea for LabVIEW to implement in its general form.

> Like I said, NI probably could add the feature that takes all the

> current values from whatever is connected to the selector

Such a feature would be a poor language construct. Consider this example:

We could stay up-to-date in the first image. But the second involves knowledge of the intervening nodes and what work they are doing. Such knowledge evaporates completely if we then create a subVI from selection:

That subVI could be doing anything.

An Enum keeps the values as part of the data type so that no matter what function you pass through, the output will be a value of the Enum. The string data type does not do this.  We could create a string type that does that, but it would be exactly equivalent to the Enum type but less efficient to store in memory.

[tst]

> Such a feature would be a poor language construct.

Editor, not language. It's purely a one time edit operation. But I perfectly understand the issues with finding the source and like I said, I don't see the need for it even if it could be made to work.