Parent class private data accessable in Child class?

[hecmar.arreola]

Hi!

I thought that this would be obvious, but my search foo fails me.  Hopefully someone would be kind enough to answer my newbie LVOOP question.

I have a a parrent class.  This parrent class contains a cluster of class private data.  I setup all the accessor methods to this data.  I create a child class that has functions that need to access data stored in its parrent class.  Its inheritence is set, but when I try to unbundle the class data all I can seem to get to is what is setup in the child class' data cluster.

I've watched a video and it looked like the data cluster magically appeared and was accessable through the children methods.  What am I missing?

Thanks for input!

-nic

[robweaver · Accepted solution]

To access the data of the parent class within the child class you must use the Read accessor methods you created for the parent class to get the parent class data (you must use the accesor methods even inside the child methods because all class data is private in LabVIEW). Hope this helps.

-RW

[hecmar.arreola]

Well, that makes sense.

One other quick question.  Is the procedure, New->"VI for Override..." from the context menu of my child class the only way to create a method that overrides the parents method?  Where is the property that defines this newly created VI as overriding my parent's VI?  Can I simply create a VI that is named the same and it have the same effect?

[hecmar.arreola]

I guess it also makes sense that within a parent class to only "get" and "set" data through the accessor methods (unless it is the accessor method you are making).

[robweaver]

As far as I know, this is the only method of creating an overriding VI, but in my opinion I think it a good way of doing it because it maintains the front panel layout, icon, and connector pane (and it might even do more than that, I'm not 100% sure) of the overriden parent method, so it saves some time and promotes good practices I think.

-RW

[Ben]

---

Nickerbocker wrote:

Well, that makes sense.

One other quick question.  Is the procedure, New->"VI for Override..." from the context menu of my child class the only way to create a method that overrides the parents method?  Where is the property that defines this newly created VI as overriding my parent's VI?  Can I simply create a VI that is named the same and it have the same effect?

---

That is the only method I use but I believe if you get all of your icon patterns and terminal marking as dynamic and all of the other rules, you should be able to do the same thing by hand (I base this guess on the fact I messed with those things and broke my ever-rides).

The only thing I think has to be done from the project (scripting aside) is to set-up the inheritance.

Ben

[hecmar.arreola]

It makes sense to use that procedure for creating a VI that is overriding.  I was just curious if there was a property somewhere that specified "This VI in this child class overrides the VI in the parent class" or how does LabVIEW know that this function is a overriding function?  When you select "New VI for override..." it doesn't regulate the file name to be the same as the parent's VI filename so that makes me think it is a property somewhere as oppose to a naming convention.

[Ben]

When you invoke it for the parent clas you are free to name it.

When creating one for the child, it gives a list of VIs found in the ancestor classes that can be over-ridden. S far as i can tell all over-ride VIs are driven by the name and the inheritance.

pseudo code

IF VI is dynamic

then

Use VI of the class data on the wire if it exist esle it parent if it exists (repeat for all levels of inheritiance until you find an over-ride)

Else

Use The Dynamic VI from the top level of the inheritance.

Ben 

[David_Grucza]

Old thread, but I'll add this answer on creating override VIs manually. You don't designate a VI as override. It is an override VI if it satisfies various conditions. A VI will override a VI in the its parent if they have the same name, the same access scope (protected, public,or community, but not private), and they each have an a class terminal marked as Dynamic Dispatch (right-click the terminal on the connector pane, and then select Dynamic Dispatch rather than required, recommended, or optional). Additionally, the connector pane data types much match. If they do not the VI will be broken because it is viewed by LabVIEW as an override VI.