Creating VI server class as child class of existing VI server class

[Wentao_Ji]

Hi all. I've been curious about this every once in a while. I have searched google and the LabVIEW doc without finding much.

The idea came up when I found it is possible to add property and method to my XControl, and then I can create property and invoke node from the right-click menu of my XControl. This is nice because it behaves just like any built-in controls. But the limitation is also obvious: my XControl has to inherit from VI server class named Control. I wanted to extend existing controls by adding new properties and methods to it. A straightforward way of doing this will be to create a child class of existing control class.

So here comes the question. Is it possible to create a VI server class, and then choose an existing VI server class to inherit from? Or is there another way to achieve similar behavior?

[wiebe@CARYA]

---

@Wentao_Ji wrote:

So here comes the question. Is it possible to create a VI server class, and then choose an existing VI server class to inherit from? Or is there another way to achieve similar behaviour? 

---

Definite no on the first question. Slightly less definite no on the second.

I'm not a XControl fan, but I thing the MO is to make a property that exposes the internally used control. That doesn't do exactly what you want, but might help a tiny bit in some cases. It goes against everything OO stands for (exposing internals, blah), so a big no-no for me...

[Wentao_Ji]

It just bugs me that I cannot inherit from a built-in class.

I wasn't trying to find a way to hack into the internals, but an OO way to extend the features of built-in controls.

You said you are not a XControl fan, may I ask why? Since I just found XControl very handy for building more powerful UI's without adding much code to the caller BD, I may need some advice to cool me down.

---

[wiebe@CARYA]

It's probably mainly because my first experience with them was terrible. I made an application with 60 screens (a kiosk app). All screens (vi's) where loaded dynamically. Worked perfectly, until an application was build. Turns out the exe would crash when an xcontrol was on the panel, while it was removed from memory. Something like that. Might be a subpanel involved somewhere. This was back in lv8, when the where brand new. Might still be a problem...

I prefer to use a class that is initialised with the parts' references. Gives the same power, but is much more flexible. The typical xcontrol appliance is a bit more complicated though, but as soon as you want more, that pays off.

Some xcontrol features are impressive, but they are a pain to work with (editing while using them), and overcomplicated.

Your own question is indeed a big downside.

Put a graph in an xcontrol, and you lose the ability to change it in any way.

It's rare for me to have a control hat has only a type, and where it's users only have to read\write to the control as if it where a black box. I always need additional events, methods, properties an general interaction with the control(s). I don see how an xcontrol would work for that.

It just adds up. Not worth the trouble for me.