topic Re: Subclasses inheritance in LabVIEW

Subclasses inheritance

s.h._tech — Tue, 22 Oct 2019 07:17:09 GMT

Hello everyone,

I have two classes "Datahandler.lvclass" and "Input.lvclass" and I am trying to understand the inheritance of the methods and variables.

I can access data of the Parent class and add it to the 'Child' using the methods of the 'Parent' (syncdata.png)

Is there a way to add all the data (and references) from the 'Parent' (merge classes, sync)? I have some notifiers in the 'Parent' and I would like to activate them in the child (since they have the same data but not the correct references)

Also some methods from the 'Parent' are not allowed to pass the datalines from the 'Child' (datatransfer_broken.png).

Is there a special classification to pass them to the child? The method from the picture above seems to have no problem passing the datalines and are created using the same template (create using dynamic dispatch vi

Re: Subclasses inheritance

cbutcher — Wed, 18 Mar 2026 19:00:48 GMT

I'm not exactly sure what you're asking for so I'll describe some aspects of inheritance, hopefully it will help or at least lead you to describe what you want that I missed.

All classes have private data. Nothing that is not part of the class can directly access this (MyClass.ctl contents)
Classes can create accessor methods (this can be done by choosing New > VI for Data Member Access). This allows something else to access (read or write or both) the private data elements
VIs (and controls) in a class have access scope: Public, Private, Community or Protected
- Public means anything can use it
- Private means nothing can use it from outside of that class
- Community means only this class, or friends of the class (configured via the Properties page of the class) can access it
- Protected allows the class, or any children of the class, to access the method. This could be a good choice for e.g. template method patterns.
Children cannot generally access the data of their parents directly. They can make use of Protected data access VIs.
A public/protected VI can provide whatever data you want (from the parent) and be used by the child to get that data.
A wire has a specific type. If I wire two different children into a Build Array node, the wire type at the output is <array of parent.lvclass>.
If the wire type is a Parent.lvclass, then VIs specific to the child (i.e. not dynamic dispatch defined in the parent) cannot be called without a "To More Specific Class" node.
- This is because the wire type doesn't know anything about that VI (it is a member of the child, not the parent)
- It doesn't matter if the actual object on the wire is/might be a child1.lvclass, you still can't call Child1.lvclass:MyStaticVI.vi (at least without To More Specific)

Does this help at all?

Re: Subclasses inheritance

s.h._tech — Tue, 22 Oct 2019 07:55:18 GMT

That helped a lot.

Now my only problem is the initial synchronization. I write some data in the 'Parent' (defined in Parent.ctl). Is there a way to get whole Cluster and not all the indiviudal elements.

When I unbundle the Parentdataline (in a dynamic dispatch method) I only get the individual elements and not the Cluster with all elements. I would like to transfer all the Parent data to the Child and not make individual lines for every entry

Re: Subclasses inheritance

Yamaeda — Tue, 22 Oct 2019 08:00:25 GMT

@s.h._tech wrote:

When I unbundle the Parentdataline (in a dynamic dispatch method) I only get the individual elements and not the Cluster with all elements. I would like to transfer all the Parent data to the Child and not make individual lines for every entry

Then don't unbundle it. 😜

You can make accessor on cluster level or even make custom ones.

Re: Subclasses inheritance

cbutcher — Tue, 22 Oct 2019 08:06:16 GMT

You could create a typedef containing a cluster that contains all of the elements, and then either directly place that cluster inside the class data of the parent (adding an extra unbundle all the time) or alternatively add a static dispatch method that unbundles the elements individually, then bundles them into this typedef'd cluster, and returns that.

The second option (not necessarily better):

Re: Subclasses inheritance

s.h._tech — Tue, 22 Oct 2019 08:13:21 GMT

That means I have to add every value from the Parent manually to the child?

Re: Subclasses inheritance

cbutcher — Tue, 22 Oct 2019 08:21:52 GMT

@s.h._tech wrote:

That means I have to add every value from the Parent manually to the child?

Hmm, no. Probably not, anyway. What do you want to do with the values, once you have them in the child?

You initially mentioned notifiers, so there are possibly alternatives (like using a parent VI that can be called by the child, and passing appropriate data or state from child to parent).

Re: Subclasses inheritance

Intaris — Tue, 22 Oct 2019 09:34:02 GMT

@s.h._tech wrote:

That means I have to add every value from the Parent manually to the child?

What? no.

Every Child is also a parent. If you add everything from the parent to the child you now have it twice. Once in the parent and once in the child.

Think of it in terms of clusters. You have a cluster which contains data. This is your parent. Now you make a child. The cluster for the child contains also data (different to the parent) but also a data field which represents the parent. The trick is that you don't have DIRECT access to this data field as a child, but your Parent implements accessory to grant you access. If you need tha data from the parent, use parent accessors. Don't double-up your data fields.

Re: Subclasses inheritance

s.h._tech — Tue, 22 Oct 2019 09:58:10 GMT

They are just there for initialization.

I think I figured it out:

Initial values are copied manually from parent to child
All parentmethods that do not allow the childclass wire are newly generated (dynamic dispatch vi again) and for some reason they now allow the childwire (maybe a bug, or because it was generated before the subclass methods)

Re: Subclasses inheritance

Intaris — Tue, 22 Oct 2019 10:09:48 GMT

@s.h._tech wrote:

They are just there for initialization.

I think I figured it out:

Initial values are copied manually from parent to child

All parentmethods that do not allow the childclass wire are newly generated (dynamic dispatch vi again) and for some reason they now allow the childwire (maybe a bug, or because it was generated before the subclass methods)

It doesn't really sound like you're figured it out to be honest.

If you have initialisation for a parent which is only setting internal values then use the parent method for the child.

If your child needs a different initialisation, make a separate method for the child. Then call one after the other.

Can you post some example code of what you're trying to do?

Re: Subclasses inheritance

s.h._tech — Tue, 22 Oct 2019 11:49:51 GMT

I initialize the parent with some values and then create a setter method to copy the parentdata to the child. I hope there is an easier way, because my parent holds a lot of data

Re: Subclasses inheritance

Intaris — Tue, 22 Oct 2019 12:21:59 GMT

I see your mistake.

Just use the parent methods on the child wire.

You can call parent methods on Parents, children, grandchildren.....

The lower of the two is the better option - much more efficient

You're overcomplicating things.

Shane

Re: Subclasses inheritance

crossrulz — Tue, 22 Oct 2019 12:40:46 GMT

@s.h._tech wrote:

I initialize the parent with some values and then create a setter method to copy the parentdata to the child. I hope there is an easier way, because my parent holds a lot of data

Why? Just create an Initialize for the child and make it "Call Parent Method". You will need to have the connector panes match, but Dynamic Dispatch will do all of the work for you. Attached is an update to your project showing how this works.

But what you seem to be trying to do is not inheritance, but composition. Composition is when an object contains another object in its private data. So what exactly is the relationship you are trying to make here?

Re: Subclasses inheritance

s.h._tech — Wed, 23 Oct 2019 05:43:43 GMT

@Intaris wrote:

The lower of the two is the better option - much more efficient

I need to do the first option, because there are more VIs called before the parent is ready to transfer the data to the child. The calling of the parent methods works. At least for methods created after the children. The older methods are not always recognized, but when I create a new dynamic dispatch and copy the whole VI it works for some reason. The classic inheritance works now.

I want to access all the data from the parent defined in parent.lvclass without creating a cluster in the definition of the class (which is already a cluster). But this has more cosmetic and accessibility reasons.

Re: Subclasses inheritance

cbutcher — Wed, 23 Oct 2019 06:42:37 GMT

@s.h._tech wrote:

@Intaris wrote:

The lower of the two is the better option - much more efficient

I need to do the first option, because there are more VIs called before the parent is ready to transfer the data to the child. The calling of the parent methods works. At least for methods created after the children. The older methods are not always recognized, but when I create a new dynamic dispatch and copy the whole VI it works for some reason. The classic inheritance works now.

Red point: Hmm... Why does the parent transfer data to a separate child object? You should just have a Child object, and store the necessary "parent-level data" in the same child object, using the Parent VIs (e.g. iniparent.vi).

Blue point: I'm confused what this means... I suspect at some point you've changed how you're creating something, perhaps from the wrong way to the right way, and now it's "working", but I'm still unsure what you're doing, so I'm not sure it's right! 😞

@s.h._tech wrote:
I want to access all the data from the parent defined in parent.lvclass without creating a cluster in the definition of the class (which is already a cluster). But this has more cosmetic and accessibility reasons.

The way you talk about Children and Parent classes makes me wonder if you in fact need a "Composition" arrangement as was previously mentioned by crossrulz, or if you're missing a key point about LabVIEW objects.

I know that when I first started using them, I also worked to place the entire parent object in the Child data using variants. When I later came back to that code, I was mystified as to what I'd been trying to do. My best guess is that I just hadn't understood dynamic dispatch very well! Some rework with the template pattern removed a large fraction of the code and made everything much cleaner.

Shane (Intaris) already mentioned (although not by name) the Liskov Substitution Principle, paraphrased as "every child is-a parent", or similar phrases. If you have a "is like a" relationship, don't use inheritance.

LabVIEW only allows public inheritance, and currently (wink wink 😄 ) doesn't have interfaces, so you can only correctly model "is-a".

For other relationships, look to composition (i.e. put an object of one class in the private data of another class).

What are your parent and child classes? Datahandler and Input? And how do they work (a description is probably fine).

Based on the names, I'm not sure that "Input" is-a Datahandler, or really that Datahandler is-a "Input", but perhaps that is indeed the case and I just haven't understood the meaning of the names correctly.

What are their respective initialization steps? Or rather, which VIs must you call on each object before you can use it? Do they share code, or purpose? Or does one just use the other (this is a composition/aggregate rather than inheritance relationship, usually).

Re: Subclasses inheritance

s.h._tech — Wed, 23 Oct 2019 07:10:22 GMT

Thanks for the detailed answer.

Since the Childclass now allows the Parentmethods I would also think that something went wrong in the creation step. With the methods I created thus far I have no problems.

The only problem I have now is that I want to access all the data from the Parent.lvclass and not put in in another cluster (my real data consists of multiple clusters and I do not want a cluster in cluster in cluster structure). Then I can create a setter method and transfer all the parent data to the child.

Re: Subclasses inheritance

thols — Wed, 23 Oct 2019 07:18:49 GMT

Have just been skimming the conversation, but "transfer all the parent data to the child", that should never be needed. Either there is a misconception or the design is incorrect. You simply access data from the parent class from the child class. When you are running the code, the created sub-class object has/can access parent class data, without transferring anything to the child (depending on access, which needs to be protected-scoped for parent->child access).

Re: Subclasses inheritance

cbutcher — Wed, 23 Oct 2019 07:22:33 GMT

From the code you just attached and the block diagram you show in your reply, you could now use the idea I suggested some time ago with a separate typedef'd cluster, not used in the private data, but only as an output. This would in your example be {Numerisch, Boolesch}.

If you don't want to bundle data specifically for output (not inside the private data, but in the accessor methods like "getparentdata.vi"), and you don't want separate accessors ("Get Numerisch.vi", "Get Boolesch.vi") then you must instead consider alternative ways to get/use the data.

You talk about a Setter method to set the data in the child, but it's still not clear why you're trying to do this. It's possible you feel like this is obvious, but it continues to escape me... Can you try explaining it some more?

Further, following my descriptions above, are you happy that your Child is-a Parent?

Re: Subclasses inheritance

s.h._tech — Wed, 23 Oct 2019 07:49:25 GMT

The 'datahandler' is the super class. I do some calculation, file manipulation, setting values that all 'Children' need. After the 'datahandler' has finished its initialization I create the 'Children' are created. These children now need the values of the 'Datahandler' (which where created earlier).

@cbutcher wrote:

From the code you just attached and the block diagram you show in your reply, you could now use the idea I suggested some time ago with a separate typedef'd cluster, not used in the private data, but only as an output. This would in your example be {Numerisch, Boolesch}.

I will use this method. I am used to have direct access to all variables of the super class without the need to implement specific setter methods from the parent (they share the same set of variables declared in the super class). It would be nice to unbundle the Elements of the 'Parent' directly in the 'Child'.

@cbutcher wrote:
Further, following my descriptions above, are you happy that your Child is-a Parent?

A parent for which class? In this example? A child can have a child (with all the methods and variables of the parent -> grandchild), but I dont think I did it here

Re: Subclasses inheritance

Intaris — Wed, 23 Oct 2019 08:08:14 GMT

@s.h._tech wrote:

It would be nice to unbundle the Elements of the 'Parent' directly in the 'Child'.

And this is precisely what you can't do.

You create accessors for the parent, and use these inthe child isntead of direct cluster access.

This is how it works.

If you want to re-create all of the data in a child, then it's going to be really inefficient.