How to access a custom control's data type programmatically?

[Adam_Boros]

Hi all,

I am looking for a way, to access my custom control's data type programmatically.

I have 25 different controls(.ctl) in my project and i would like to use their different data types in different cases.

I seem to be too lazy to write the 25 cases one by one, so i built an array containing the controls' paths. The controls are ranked 0..24 and each case should use the data type determined by the value wired to the case selector (0..24).

I guess I need to obtain a reference to the controls (using the paths) but I cannot find any property node, that returns the data type (or value) of a control. Maybe I'm casting the reference to the wrong class.

Below is a picture of my array of control paths.

Thank you in advance

Adam Boros

[Bob_Schor]

I really don't understand the context in which this problem arises.  I must generate a hundred Type Definitions in the course of a large LabVIEW Project, but there's never a question "which one to use".  The most obvious time there is an "option" where the Type can appear as a "variable" (in my limited experience) is when you instantiate a Variant using Variant to Data where you do need to know the type.  

It sounds to me like the road you are going down is fraught with hidden dangers.  If you are really doing sophisticated stuff and there is a real need for this (strange) flexibility, have you considered LVOOP and Inheritance?

Bob Schor

[Adam_Boros]

Thank you for your answer.

The task is to communicate data from a Rt target to a host PC. The number of input channels is a variable, therfore the type of the network stream is also varying. The type defs contain clusters with different number of numerics.

I wouldn't normally write such a code, but I was asked to solve the problem.

I already created the cases one by one, but I'm still curious whether there is a universal solution. I should dig into OOP then.

Adam Boros

[Alexander_Sobolev]

Bob is right, but technically it is possible, I got this from intestines of Open G ini files library.

[Bob_Schor]

---

@Adam.boros wrote:

Thank you for your answer.

The task is to communicate data from a Rt target to a host PC. The number of input channels is a variable, therfore the type of the network stream is also varying. The type defs contain clusters with different number of numerics.

---

I'm also using Network Streams to communicate with an RT Target.  In my case, I have 4 Streams.  Two are Message Streams, with the Type being a Cluster of Msg (String) and Data (Variant), one Host to Remote (to send the Remote set-up parameters or signal "Start Trial", for example) and the other Remote to Host (to pass Device properties and Remote Signals to Host).  The other two Streams are RT-to-Host.  One is a Stream of Samples, digital data collected at 1KHz from a variable (but fixed during the Initialization process) number of (mostly Analog) channels, and the other is "Event" information, a mixed bag of (mostly) Digital "stuff", like the values read from a DIO port when a bit changes, or the State of the RT's State Machine when a State Transition occurs.  These Events occur asynchronously and "rarely" (compared to the 1KHz Samples), but need a flexible Data format.   As it happens, I was able to achieve this with a Cluster having three components:  Event Time (U32), Event ID (an Enum of 10 Elements that helps interpret the next component) and Event Data, saved as a String.  When it comes time to save an Event, the "saver" knows what is being saved, so can easily set the appropriate Event ID (and having an Enum value wired in makes the code somewhat "self-documenting").

On the Analysis end, having a pre-defined Enum for the Event ID makes the code for interpreting very simple.  Yes, you need a Case Statement, as the binary value of a DIO written as a string representing a U16 integer (e.g. "2048") would be treated differently from the String representing the RT's State Transition ("Start Trial").  Having an Event TypeDef simplifies the process immensely.

Bob Schor

P.S. -- as Alexander points out, you could cast your arbitrary variable to a Variant and then start taking the Variant apart to get at its individual components.  This can get messy fast, especially since some of those components are, themselves, "composite", such as Array, Cluster, and (gulp) Variant, suggesting a recursive solution involving reentrant VIs ...