Variant control (union)

[Mister_Rose]

I'm not sure if a variant is what I am looking for.

What I want to do is to have a data type that can be any one of a set of different data types. Specifically, I am looking for a way to abstract all instruments into one generic "instrument" type. Depending on what the user selected, the control would present the proper sub-controls for the user's choice. So if they wanted a GPIB instrument, the would select a "VISA" type and then the contol would present a VISA control. If they selected a DAQchannel, a DAQchannel control would present itself and allow the user to configure it.

The closest that I have come is to put all the types in and leave it to the user to configure the proper control. Any accesses would look at the tye they picked and the read the appropriate control. But this is a bit sloppy because all the other options are shown and the user could possibly configure the wrong one. Not to mention the extra memory used storing all the empty and unused controls.

In C, I would use a union and code it something like this (I apologize for any C syntax errors)...

typedef enum {
    eVISA = 0,
    DAQchannel,
    whatever
} TYPE_E;

typedef struct mystruct {
  char[32]    name;
  TYPE_E   type;
  union data {
    VISA_T               visa;
    DAQchannel_T  daqchan;
    WHATEVER_T  whatever;
  }
} MYSTRUCT_T;

[tst]

I assume you don't know C++, because then you probably would have said "I want classes".

Essentially, what you're describing is an object oriented architecture with inheritance and overriding methods. If you're using LV 8.2 or above, you have this built in. If you're using an earlier version and you still want inheritance, I think you would either need to buy one of the Endevo GOOP toolkits or get Sciware GOOP. If you want, there are several other free GOOP implementations around.

Basically, what you would do is create a method for each class called "Show Config Screen.vi" or something similar and you would then call that method on your object. The VI itself can open a new window or work with a subpanel. The key is that the correct VI will be called automatically based on the type of the wire.

You should note, however, that you might not need inheritance. One way to do this (although not a nice one) is to embed the type and data in a variant and pass that variant around. For example, you could have a cluster which would hold a typedef enum which represents the type and a variant which holds the data (e.g. your object reference). When you need the actual data, you get the value of the enum and feed it into a case structure and do the class specific code inside the case. The main problem is that you have to add code to the case whenever you have a new type.

[Mister_Rose]

I see how this can work in code. But I am not sure how this would work for a control that the user can work with. I may be asking a bit much here, but what I was hoping for was some way to create a custom control that would change its appearance based on an enumeration. So when the user selects the enumeration, the control will show the appropriate subcontrol for the user to work with.

I probably could use a tabbed window without showing the tabs. Then whenever the enum is changed, the tab control shows the appropriate panel.

Is there any way to put code into a custom control, so that I can hide this code from the calling window?

[tst]

What you want is an XControl, which is available in 8.x, but I would suggest that you examine whether you can move the GUI code for the type-specific controls to subVIs and embed a subpanel in the XControl to display those GUIs. An example of this would be the LV Options menu, where you select from a list of possible screens and the GUI for each screen is a seperate VI which appears in a subpanel.

[Mister_Rose]

Here is a VI that illustrates what I am trying to accomplish. I'd just like to embed this code in a custom control to give it custom behavior. But custom controls cannot have code (as far as I know).

[tst]

As I said, you want an XControl, which can have code and even run at edit time, but is relatively complicated.

My suggestion with the subpanel was to get rid of the tab and use a subpanel instead for the GUI. I believe you should be able to do that with an XControl.

And again, you should probably check out LabVIEW classes.

[falkpl]

Am I missing anything or is this over complicated?  The enum can be just a typdef enum in labview and the struct can be a simple cluster (again typdef)  As for the union the purpose of a union of stat is to conserve space in or nolonger prescious RAM.  back when you had 64k of ram it was very important to not over use RAM unions allowed for stuffing many bits of data into a single memory location.  I havent done this in years so my memory could be fading.  But you could just use 3 fields in a cluster and pick off the frquired field in a particular situation.  Since the typdef is expandable and will auto update you can always add additional fileds.  This is not quite as elegant as classes with inheritance but will work fine.  The downfall each instance will add a few extra bytes but unless you have millions of instances I wouldnt worry about it.

Paul

[Mister_Rose]

The main thing I was looking for was a way to drop a customized control onto my front panel and be done with it. All the "special" code is embedded within the control itself, instead of me having to have code all over that operates a cluster of normal controls.

I'll look at XControls and see what that offers. I know almost nothing about those.