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!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

Allow vi server reference type as case selector

Status: New

reference case structure.jpg



I have pondered this and not sure it is possible but it would be nice to allow using case structures to work with vi server references.  It is very tedious to test each type with a cast to more specific and the for each type and check for error (current method or itterating through the class hierarchy).

I know that subclasses pose an issue, I would like to see for the case structure to limit each case to select the highest level (ie g object) and the distince cases are error or any direct class child of the specified parent type class.


The Use case I see is for handling itterating through controls from an array of controls (if the control is a boolean do something different than if the reference is to a string control).

Could be very nice for scripting.






Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
NI Employee (retired)

Yes!  This could eliminate a lot of testing to find if a reference is in a class of objects.

This account is no longer active. Contact ShadesOfGray for current posts and information.
Trusted Enthusiast

I have several ideas where this would save me a ton of time. 

The purpose of a case structure is to allow for efficient access to select one choice in a discrete list of options instead of a huge number of if then else structures.  Making a tool like control to XML or iterate all controls and handle by type would be quick to implement and very readable. Scalability with new versions of LV (as new structures are added to the vi server hierarchy) can be enforced by the default case (is it is not used code will break and make the new version handle new data types).

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
Active Participant

I'm also very interested in this feature. Up to now I used the GObject.ClassName attribute that is set to the correct child class name to add only one layer of "To More Specific Class" functions (I'm pretty sure I saw this method somewhere here on the forums):




I'd even go further and want the "To More Specific Class" function to be included within the selector terminal of the case structure so that Property and Invoke Nodes can directly be attached to the wire (modified picture from above):



Trusted Enthusiast

Exactly the case I am thinking of, why have to generate 10's or 100s of string canses and spectal cast to a specific gObject type if the wire already knows what it is and a case selector will handle it for you.

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA

Great idea! Kudos!

I like the idea of the automatic cast to the specific class, too.


Let me just aks the design question that comes to my mind in this context:

What if you have several values for one case (for example a case for both numeric and string controls)?

To which class will the wire be casted?

I assume this would have to be the nearest common ancestor class of all the possible classes (in my example case "Control Refnum"). Basically this would be the same type that you get when you build an array out of all the reference types of a case.

Trusted Enthusiast

What I was thinking interms of casting is that we specify the toplevel cast hierarchy (ie control or gObject), the cases are each direct subclass and a special not casted/ error case.  So for the control case if the incomming reference is a ref to a string the string case is used.  if the incomming case is a lower level class, it will go to the parent class (least specific parent class).  From each level you can nest a more specific case structure.  This was what I had in mind but am completly opened to better ideas since I have not put that much though into the implementation just the need for a clean method of working with the Gobjet hierarchy

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
Proven Zealot

For the record, if we ever do this -- and R&D has talked about it a few times -- this would apply to all class hierarchies: VI Server, LV classes, .NET refnums, DAQ and hardware refnums, LV variants, and any other type that has hierarchy like that.


It would fit very well with Actor Framework (thx Aristos Queue).

Actor message implementation would be simplier and more readable.

We would be close to an Actor implementation à la Scala (my other preferred language).

Exciting !

National Instruments Alliance Member
National Instruments "Certified LabVIEW Developer"

Is that wonderful idea abandoned ? (7 years later !)


I thought about it recently especially when looking at the implementation of "Get GObject" from the scripting API, which I find a bit complex for what it actually is (this is only one example among other applications, but I find this one particularly apropos) :




... which could easily become something more or less like that with the new case selector :



We could also have an "Invalid Refnum" case, which would also make the refnum validity check easier.

The Selector Label could even benefit from Autocompletion, displaying only the possible subclasses of the class wired to the Case Selector terminal.

Knight of NI

raphschru, your code can be simplified quite a bit by using the ClassName property as stbe shows above.

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