Why is my vi for override always call the parent method?

[ben64]

Decided to give it a try with LVOOP and so far the least I can say is that it had been a very frustrating experience (I guess I'm not the first one). I'm trying to create power supply classes for dynamic dispatch, for the moment I'm keeping it small with a parent Power Supply.lvclass and a child Simulated Supply.lvclass.

In the parent class I created 2 vi for dynamic dispatch, an Initialize.vi and a close.vi. The parent class inherit from the base LabVIEW Object and Transfer all Must Override requirements to descendant classes is checked. Both Initialize and Close vi were created using new vi from Static Dispatch Template and their item setting Require descendant class to override this dynamic dispatch vi are checked.

When I'm creating a vi for override in the child class this is what I get:

I compare my settings with the ones from the Hardware Abstraction Layer example project and they are similar so I really have no idea why my vi for override is always calling the parent method. I must have tried a few times all the possible combination of settings with always the same result. So my guess is I'm missing something very fundamental but I can't figure out what it is. I attached the library containing the classes (could it be because the classes are in a lvlib instead of a lvproj?)

Ben64

[nathand · Accepted solution]

This is the default behavior when you create an override, since it's very common for a child to call the parent implementation. If all you want the child to do is to call the parent, there's no need to create the child method at all - if the child method doesn't exist, the parent method will be called. Otherwise, you can edit the child method to do whatever you need it to do, and you can delete the call to the parent method unless the parent method is configured, in the class properties, to require that all child implementations call that parent method.

[deceased]

I must admit, I find the same to be counter productive.

The first thing I do is delete the call parent and put in a case structure on the errors and wire the object through - over and over again.

If I wanted to call the parent, surely I wouldn't create an override for that VI.

[cbutcher]

There are plenty (he says...) of good cases for calling a parent. One I was working on today involves an LDV system. The manufacturer divides devices into two types, but the driver is the same for both - you just set a configuration flag before making subsequent calls.

Essentially all of the calls to the LDV (the manufacturer uses LDA as the name, but it's more or less the same) are applicable to the PDA measurements too - you can get velocity, time, validation %, ... for both. For the PDA measurements, you can also get particle size, particle sphericity (I think?!) and so on. These aren't available for the LDA measurements.

So, I create a base class for LDA measurements and subclass it with a PDA class. When I receive an event telling me acquisition has finished, a dynamic dispatch method is called. By using 'Call Parent Node' in the PDA implementation, I can avoid both writing the 'Read Velocity' method twice (normal inheritance gets me this though - not specific to call parent node) and further, placing them all also in the 'Read Data - All.vi' or similar. Now, my PDA version is just 'Call Parent Node' followed by 'Read Particle Size' and so on.

[cbutcher]

---

@deceased wrote:

I must admit, I find the same to be counter productive.

The first thing I do is delete the call parent and put in a case structure on the errors and wire the object through - over and over again.

---

As a side note, with LV201(5? 6?) you can just click the Call Parent Node and hit Ctrl-Space, Ctrl-R and it's removed with the wires remaining. Plus it fits my hand nicely!

The error wires is annoying though...

[deceased]

---

@cbutcher wrote:

---

@deceased wrote:

I must admit, I find the same to be counter productive.

The first thing I do is delete the call parent and put in a case structure on the errors and wire the object through - over and over again.

---

As a side note, with LV201(5? 6?) you can just click the Call Parent Node and hit Ctrl-Space, Ctrl-R and it's removed with the wires remaining. Plus it fits my hand nicely!

The error wires is annoying though...

---

Apologies for the drifting off topic. The Ctrl-Space, Ctrl-R functionality is now on the right click menu too.

I like to have a error/no error case structure in there, so it still feels like a lot of wasted steps for me each time.

In the instances where I want to use the parent but extend, its easy enough for me to add it inside the child.

When I only want the parent, I dont create a child override (which will call parent instead anyway).

Guess its horses for courses, but I think the override VI should be the same block diagram structure as given then you created the parent VI (an empty error case structure with the class wired through it).

[crossrulz]

I'll have to do some digging, but I am think there is a template for the override method that you can edit.  I know there are templates for the Dynamic Dispatch and Static Dispatch VIs.

[cbutcher]

---

@crossrulz wrote:

I'll have to do some digging, but I am think there is a template for the override method that you can edit.  I know there are templates for the Dynamic Dispatch and Static Dispatch VIs.

---

I think the classes in ...\National Instruments\LabVIEW <version>\resource\Framework\Providers\LVClassLibrary\NewAccessors might be what you're looking for. There's a subdirectory (at least for 2016) named OverrideRetooler which has a VI with the following comment:

When "New >> VI For Override..." is used to create a VI, this subVI will be invoked if the VI is created successfully after all other work to create the VI has been completed. Users may edit this subVI to add any instructions they wish for customizations of the newly generated VI.

I don't know what modification you'd go about making, though... Perhaps it would be easier to find the VI responsible for placing the node in the first place and then removing functionality, rather than scripting an error case and removing the CPN node after it had already been placed.

[ben64]

Thanks to all, I agree with deceased that it is not very intuitive, I would have expected something like that:

Ben64