LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

new feature: "copy case for every value"

Status: New

Editing multiple cases in one case-structure to make them execute nearly the same piece of code is a pain at the moment. Combining the functionality of "Add case for every value" and "Copy case" would be such an helpful feature to have all cases look nicely and speed up changing the relevant parts of code in the case-structure.

 

Why would one need such a feature? Imagine some kind of generic API that manages multiple incoherent hardware interfaces in one place. Depending on which hardware interfaces are needed (dynamically) there's an array handed over to the API that contains the interfaces to start (asyncron). Let's say the API decides via a case-structure which interfaces are "named" to be started, then the only thing to change in every case is the "static vi-reference", but at the moment you could either copy one existing case x times for every startable hardware interface and have to change the case-name and the "static vi-reference" or you could add cases for all values but have to fill every case's funtionality anew.

5 Comments
Knight of NI

I can already hear the cries for you to use OOP (given your use case)...


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Knight of NI Knight of NI
Knight of NI

Here's my use case where I often wanted it - I have a new enum case structure which has a wire coming out of it. I want every case to have a different value wired to the tunnel. What I usually do today is wire something to it in one case and then duplicate the case for all the values (and if I don't remember what they are, I usually have to do it until I get an empty case and then undo). This option would replace that sequence of operations.


___________________
Try to take over the world!
Proven Zealot

Same as Tst, nothing whatsoever to do with LVOOP

Proven Zealot

Everything to do with LVOOP. If you're copying frame after frame except for a core piece, that's exactly when you should be using an LV class hierarchy to dispatch on the core piece. Ditch the enum entirely (and it's almost always attendent variant/flattened string/magic data storage thingy) in favor of a type-safe, robust implementation and generally higher performance (because of that data payload) using LV classes. This is one of the areas where classes have an unabashed claim to superiority for software architecture.

Knight of NI Knight of NI
Knight of NI

AQ, if there's a lot of copied code then you're probably right, but if I just want to convert one enum to another (or to another series of values), I have no intention of building a whole class hierarchy. I just want a VI with a case structure (in this specific case, it could also simply have an array constant with Index Array, but this is not the only use case).


___________________
Try to take over the world!