LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

labview oop question: MUST A child class implement all parent methods?

It is my understanding that when a child class is created from a parent class that the child MAY override the parent class methods (VIs) but it is NOT required to. And that if a child class does not have a VI that is in the parent, that at run time, the parent VI will be used (dynamic dispatch).  However, my LabVIEW code doesn't work (I know it's vague) when my child class does not have all the same VIs as the parent class. My parent class DOES have implementation code inside all of its VIs. I have many child classes of the parent and only one of them needs to implement different code for say a Stop VI. All other child classes are ok using the parent implementation of the Stop VI, so why should I have to create Stop VIs in all my child classes?  I have done some reading. In the LabVIEW help it mentions in various places an in various examples that the child class CAN override the parent methods. And there is even a parameter to force all children to override. However, I cannot find a statement anywhere that explicitly says that a child class MUST override ALL parent method VIs, or a statement that say that a child class DOESN'T HAVE TO override the parent method VIs.  I would think this would be default behavior but perhaps there is an obscure setting I'm missing? ( I didn't see anything applicable in the class properties dialog under inheritance.

 

Details on specific error (though I don't think related to my question):

The 'offending' omitted VI contains nothing but a DAQmx Stop Task and Clear Clear Task. Note that the parent Stop VI is indeed called, however, DAQmx Stop Task produces an error Error -200088, Task specified is invalid or does not exist. I create a child Stop VI with the exact same Stop Task and Clear Task, the child Stop VI is indeed called dynamically at run time but I do not get this error.

 

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 1 of 13
(5,033 Views)

No, a child done not have to override all parent methods.  Only those explicitly marked as "must override" have to.

 

As far as you actual issue, I would guess you have a wiring error in your child class in a method called earlier.  Can you supply some code that shows your problem?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 13
(5,017 Views)

Thanks for the sanity check. As for some code, it's not easy to create a snippet since the code is dynamically dispatched, right?

 

As for the wiring error, I suspect you may be right. The parent class private data control is used to pass the DAQmx task handle (as well as some other values).  Since the problem I am getting seems to be with the task not getting recognized, I suspect this is part of the problem. I believe this is the problem. (ignore the broken wired due to class not attached)

 

2017-10-31  LabVIEW Passing DAQmx Handle re-bundle.png

Perhaps I should pass the class reference all the way through and not re-bundle it?

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 3 of 13
(4,992 Views)

TeraTech wrote:

 

Perhaps I should pass the class reference all the way through and not re-bundle it?


Correct.  There is no point in getting a reference and writing it right back in the same place; the value of the reference is the same.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 13
(4,983 Views)

"...no point in getting a reference and writing it right back in the same place."
Except for the task is first created, right?  

I removed all the "re-bundles" in all VIs in the parent and child implementations, except, as mentioned in the class that first created the task.  It did not fix my issue.

2017-10-31  LabVIEW Passing DAQmx Handle no re-bundle.png

The the crux of the issue is when their is no child implementation of Stop (which does the Stop and Clear task) the parent implementation of the Stop VI does not stop and clear the task because I can see the output still running on my scope.

 

Here's one other curious thing - and likely the reason why things break when dynamically resorting back to a parent implementation at run time. The parent has a cluster of elements (including the DAQmx task) while the child class appears to have it duplicated inside its own private data.  This may have resulted because to create my parent class, I copied (and renamed) my original class (now a child) and changed the inheritance to point to the newly created parent.  Trouble is, I don't know how to fix it.

 

2017-10-31 LabVIEW Class private data diff.png

2017-10-31 LabVIEW Class private data diff_controls.png

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 5 of 13
(4,973 Views)

TeraTech wrote:

Here's one other curious thing - and likely the reason why things break when dynamically resorting back to a parent implementation at run time. The parent has a cluster of elements (including the DAQmx task) while the child class appears to have it duplicated inside its own private data.  This may have resulted because to create my parent class, I copied (and renamed) my original class (now a child) and changed the inheritance to point to the newly created parent.  Trouble is, I don't know how to fix it.


Yep, that is definitely your issue.  The immediate solution is simple: remove those parameters from your child class.  But then that will break a bunch of stuff.  So you will want to make "protected" VIs that the child classes can call to act on the parent's private data.  By using the protected access, only children of the class can call them.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 13
(4,967 Views)

"...remove those parameters from your child class.  But then that will break a bunch of stuff. " Yup. Tried that.
Creating accessor VIs to access simple numerical data between parent and child seems cumbersome. Does that mean that inside all of my child classes I would have to call this accessor VI to get to read/write this data? 

 

It also seems that accessor VIs are for VIs that are not children to access private class data? It follows that there should be a more elegant way to pass "common" (friend?) data between the parent and children and between children.  I don't understand why the data (controls) inside the parent class's control isn't accessible to its child classes.

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 7 of 13
(4,953 Views)

@TeraTech wrote:

Does that mean that inside all of my child classes I would have to call this accessor VI to get to read/write this data?


That is correct.  Another option is to make methods that actually do the actions you need to perform on the data so that the child does not care about the parent's data.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 13
(4,934 Views)

If I do either of those things, then I would then have to create a Stop VI in the child class, which uses an accessor method to get to the DAQmx task value in the parent... which defeats point, and that is to not have to create a child implementation of a parent class if the parent's method is sufficient.

So in short, there is no way to pass data on the "object" wire that that interconnects objects (method VIs) between parent and child implementations of those methods?  Each class definition has a control for data, which is apparently private to the class, whether parent or child. You are allowed to unbundle that object wire to access that control's data, but only within the class itself? Is this because my child classes are in essence overriding the parent's control with its own implementation of the control? If my child class contained an empty control, would the child then be able to access the parent's control by unbundling the object wire?

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 9 of 13
(4,915 Views)

@TeraTech wrote:

If I do either of those things, then I would then have to create a Stop VI in the child class, which uses an accessor method to get to the DAQmx task value in the parent... which defeats point, and that is to not have to create a child implementation of a parent class if the parent's method is sufficient.


I don't see how the accessor method forces the child to override any method.  Let the parent close the DAQmx task.  Also, you do have the Call Parent's Method function which can be used to act on the data stored in the parent.

 

 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 13
(4,908 Views)