lvoop class variable as child

[Dirk J.]

I have the nagging feeling I'm overlooking something here...

I want to create a an instance of class "child" inheriting from a specific instance of class "parent", keeping "parent" values.

To clarify, lets say I have a class parent.lvclass with some attribute A which is initialized at some value.

After that, I want to create (a couple of) instances of child.lvclass /keeping/ the previously initialized value of A.

What I've seen sofar, is that if I try to directly upcast parent --> child; I get an error 1448 saying Bad type cast. LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class. Other casting (child --> parent --> child) lose the parent settings.

Any thoughts?

[Yair]

There might be better ways (I'm just getting into LVOOP myself), but can't you do it manually by creating a constructor VI, wiring the parent object into it and then unbundling and bundling to rebuild the data?

Or do you want to avoid having to do it manually?

[Dirk J.]

QUOTE (Yen @ Apr 18 2008, 11:56 AM)

Or do you want to avoid having to do it manually?

Well, as much as possible. This is more or less how I do it now. The problem is, that if I add attributes to the member class later on, I have to modify the constructors of all child classes.

[jdunham]

QUOTE (Dirk J. @ Apr 17 2008, 02:16 PM)

I have the nagging feeling I'm overlooking something here...

I want to create a an instance of class "child" inheriting from a specific instance of class "parent", keeping "parent" values.

To clarify, lets say I have a class parent.lvclass with some attribute A which is initialized at some value.

After that, I want to create (a couple of) instances of child.lvclass /keeping/ the previously initialized value of A.

What I've seen sofar, is that if I try to directly upcast parent --> child; I get an error 1448 saying Bad type cast. LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class. Other casting (child --> parent --> child) lose the parent settings.

Any thoughts?

I don't understand how you can "Create an instance" with previously initialized data, since labview classes are by-value. Are you just branching the parent wire and then casting it as child? I think if you post some example code, you will get more responses.

[Dirk J.]

QUOTE (jdunham @ Apr 18 2008, 09:34 PM)

I don't understand how you can "Create an instance" with previously initialized data, since labview classes are by-value. Are you just branching the parent wire and then casting it as child? I think if you post some example code, you will get more responses.

There's not so much to post since casting does not work. (I get an "Error 1448 occurred at To More Specific Class": Bad type cast. LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class.)

Yen's solution obviously works well, but potentially takes a lot of coding.

An example situation is with dialogs. Suppose I have a class "CommonDialogs" with properties such as 'owner window', 'allways on top'; etc.

I can have a number of child class such as "FileDialog", "PrintDialog", "FontDialog"; you get the idea.

Suppose in an application each are needed.

I can create instances of each class, and for each class set the inhereted properties from Commondialogs, all to the same value.

The reason for my question is that I would rather have 1 instance of CommonDialogs, with all the values set as needed, and subsequently create instances of FileDialog, PrinDialog etc using the CommonDialog object as parent, retaining its values.

[Aristos Queue]

QUOTE (Dirk J. @ Apr 18 2008, 07:08 AM)

Well, as much as possible. This is more or less how I do it now. The problem is, that if I add attributes to the member class later on, I have to modify the constructors of all child classes.

You only need one VI for all your child classes. What you want to do is create a single VI on your parent class that has two inputs and two outputs, all of which are of the Parent type. And then... oh, heck. Instead of typing this out, I'm just writing the VIs. Here you go... Open the project and then look at "Demo.vi"...

Download File

Edited June 3, 2011 by Michael Aivaliotis
Fixed File Download Link.

[Dirk J.]

brilliant! thanks a lot!

QUOTE (Aristos Queue @ Apr 19 2008, 07:10 PM)

And then... oh, heck. Instead of typing this out,

ok,ok, point taken :-)

[Yair]

Very nice :thumbup: .

I didn't realize that this happens for any input->output combo of an inherited class.

[Aristos Queue]

QUOTE (Yen @ Apr 20 2008, 02:15 PM)

I didn't realize that this happens for any input->output combo of an inherited class.

On dynamic dispatch subVIs, it only works for the dynamic input and dynamic outputs.

On static dispatch subVIs, it works for all LVClass inputs and outputs.

The reason for the limits on the dynamic dispatch subVIs is that a whole batch of subVIs can be invoked, and we can't guarantee that every subVI that could possibly be invoked will preserve the runtime data type (remember that LVClasses assume that at any moment you could load another child class into memory even while the VIs are already running).

The static dispatch subVIs will make outputs match the inputs as close as possible. In fact, if an output depends upon two inputs, the output will become the nearest common ancestor to the two inputs.