Another OOP issue with inheritance, actual project

[GregFreeman]

This is the actual project I'm working on and somewhat relates to my last post in this forum. In my event structure, there are broken wires. I understand why but I was wondering the best way to go about fixing this. What my code is doing is reading an ini file and populating an array of amplifier classes (each type of amp has its own class) that inherits from the base class amplifier. I want to be able to take this array of sub classes that all inherit from my base class and wire it up to functions such as operate, standby, reset etc. However, most of those methods are only methods of one specific class type, and don't relate to all classes. Will I still need to make the functions polymorphic (dynamic dispatch) and initially define them in my base class even though they don't relate to all sub classes? This is for the situation of being able to index the array and wire the class elements to different methods.

Sorry that's a bit wordy, hopefully seeing my VI's will help the question make more sense so I've attached them. I'm thinking I will have to put the methods in the base class and make them dynamic dispatch and for the amplifiers that they don't apply, just leave them blank but I wanted to see if there were other options. If clarrification is needed let me know.

As always, any other comments are also appreciated. Thanks.

[Shaun Hayward]

This is the actual project I'm working on and somewhat relates to my last post in this forum. In my event structure, there are broken wires. I understand why but I was wondering the best way to go about fixing this. What my code is doing is reading an ini file and populating an array of amplifier classes (each type of amp has its own class) that inherits from the base class amplifier. I want to be able to take this array of sub classes that all inherit from my base class and wire it up to functions such as operate, standby, reset etc. However, most of those methods are only methods of one specific class type, and don't relate to all classes. Will I still need to make the functions polymorphic (dynamic dispatch) and initially define them in my base class even though they don't relate to all sub classes? This is for the situation of being able to index the array and wire the class elements to different methods.

Sorry that's a bit wordy, hopefully seeing my VI's will help the question make more sense so I've attached them. I'm thinking I will have to put the methods in the base class and make them dynamic dispatch and for the amplifiers that they don't apply, just leave them blank but I wanted to see if there were other options. If clarrification is needed let me know.

As always, any other comments are also appreciated. Thanks.

To work be able to wire your generic "Amplifier.lvclass" wires to the commands of the specific amplifiers, then yes, you will have to create the dynamic dispatch VIs in the parent class.

One thing that I have done in the past for such "not always implemented" functionality, is to have the parent VIs raise an error for "unsupported function" (using whatever custom error code you feel like) - that way, if the specific child amplifier class does not implement a particular command, you will get a known error that can be nicely handled by the rest of your app. If your using LV 2009, this can then be nicely extended using the "must override" checkbox in the class "item settings" property to say that certain functions (such as init, or power on/off) must always be implemented (if those VIs are not replaced then you will actually have broken run arrows).

[GregFreeman]

To work be able to wire your generic "Amplifier.lvclass" wires to the commands of the specific amplifiers, then yes, you will have to create the dynamic dispatch VIs in the parent class.

One thing that I have done in the past for such "not always implemented" functionality, is to have the parent VIs raise an error for "unsupported function" (using whatever custom error code you feel like) - that way, if the specific child amplifier class does not implement a particular command, you will get a known error that can be nicely handled by the rest of your app. If your using LV 2009, this can then be nicely extended using the "must override" checkbox in the class "item settings" property to say that certain functions (such as init, or power on/off) must always be implemented (if those VIs are not replaced then you will actually have broken run arrows).

Thanks for your response. Just one more question.

Do you mean raise an error in the child class? How would you test the input wire type in the parent class? Wouldn't you want LabVIEW to delegate which child method to call and if it gets called then set the error there?

[Shaun Hayward]

I've attached a little example of what I was talking about.

LabVIEW does select the appropriate VI, but the raising of an error is used to tell the main application that whatever was requested did not get done because that particlar amp does not support the particular function.

In the attached example, Apmplifier specifies that all child objects must override Init and Power On-Off, ie if they dont have these VIs then everything will be broken (this is a really nice improvement in LV 2009), however, the "Set Volum.vi" is "optional". The base class's version of this VI simply generates an error, so if a child classe does not replace this VI with something else, the error will be generated (if the VI is replaced, then the alternative functionality will be used instead).

Hope this helps!

Shaun

Framework Error Example.zip

[GregFreeman]

I've attached a little example of what I was talking about.

LabVIEW does select the appropriate VI, but the raising of an error is used to tell the main application that whatever was requested did not get done because that particlar amp does not support the particular function.

In the attached example, Apmplifier specifies that all child objects must override Init and Power On-Off, ie if they dont have these VIs then everything will be broken (this is a really nice improvement in LV 2009), however, the "Set Volum.vi" is "optional". The base class's version of this VI simply generates an error, so if a child classe does not replace this VI with something else, the error will be generated (if the VI is replaced, then the alternative functionality will be used instead).

Hope this helps!

Shaun

One issue, I'm using 8.5 Sorry, I haven't set up my signature yet.

[Shaun Hayward]

In that case, ignore my comments about the "must override" option -> this isn't available in LabVIEW 8.5. As an alternative, I often have my parent VIs return one of two error codes - one for the "you really must implement this VI" error, and one for the "this optional feature was not implemented error". The downside with this approach (when compared to LV 2009) is that you only find out about the missing important VIs at runtime.

Here's a back-saved version of my example.

Shaun

Framework Example.zip

[GregFreeman]

In that case, ignore my comments about the "must override" option -> this isn't available in LabVIEW 8.5. As an alternative, I often have my parent VIs return one of two error codes - one for the "you really must implement this VI" error, and one for the "this optional feature was not implemented error". The downside with this approach (when compared to LV 2009) is that you only find out about the missing important VIs at runtime.

Here's a back-saved version of my example.

Shaun

Perfect, thanks!

[MartinMcD]

Hi there,

My company is being slow to update - would anyone be able to save me out an 8.2 version please?

Thanks very much,

Martin