Allow vi server reference type as case selector

[falkpl]

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.

[DFGray]

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

[falkpl]

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).

[stbe]

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):

[falkpl]

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.

[silmaril]

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.

[falkpl]

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

[AristosQueue (NI)]

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.

[Adnan[Safran]]

It would fit very well with Actor Framework http://decibel.ni.com/content/docs/DOC-12737 (thx Aristos Queue).

Actor message implementation would be simplier and more readable.

We would be close to an Actor implementation à la Scala http://www.scala-lang.org/node/242 (my other preferred language).

Exciting !

[raphschru]

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

I thought about it recently especially when looking at the implementation of "Get GObject Label.vi" 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.

[crossrulz]

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