LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVOOP Dynamic Dispatch and Inheritance

Hi Everyone,

I'm busy semi-finalising my first LabVOOP set of drivers.

I've implemented the code for several different spectrometers we have in use.  Some are interfacing via DLL, others direct per DAQ card and so on.  I've implemented a standard set of functions (Set Integrationt ime and so on) and the implementation is fully encapsulated within the objects.

I wanted to have an "Open" function which used dynamic dispatch inputs, but I've run into a small problem.  It may have to do with the way I've implemented my inheritance within my object family.

I have a single base class "Spectrometer".  Here I have defined all of the general purpose functions and data required.  Some public, others protected.  Ths "open" function of this base class accepts an object as input and is set to dynamic dispatch.  This way I wire a constant to the "open" function to control which spectrometer type I'm using.

Then I have a few different types of spectrometer inheriting from this base class.  Each of these have their own "open" function defined.  So far so good.  With this structure, everything works as planned.

If, however I want to implement a Spectrometer -> Manufacturer 1->Model 3, Model 4 type of inheritance where models 3 and 4 of Manufacturer 1 share a lot of functions but have some data differences, then everything works still, with one small problem.  Due to the propagation of the "open" dynamic dispatch function, I am forced to expose an "open" function for a "Manufacturer 1" object, even this onject doesn't reflect any real-world usage.  I can implement some error mesage when the user tries this, but it's still possible to wire it up, and the program SEEMS correct, no error messages until run-time.



I also tried adding an adaptive structure within the "open" function of the "Manufacturer 1" class, but if the data type of the output is anything different from the input class, I get an error message saying that the output is not linked to the input.

"This tunnel or shift register lies on the path between a dynamic input front panel terminal and the dynamic output front panel terminal. All of the data paths that lead to the dynamic output terminal must originate at the dynamic input terminal. This input of this terminal either originates at a different source, or the wire passes through some function that does not guarantee runtime type preservation. Note that "Use Default if Unwired" does not work to connect the dynamic input front panel terminal to the dynamic output. You must actually wire the tunnel in all cases."

Is what I'm describing here properly explained?  Would this normally be a case for multiple-inheritance?  Is there any way to change this behaviour without implementing Model 3 and Model 4 independently of each other (duplication of data and methods which are otherwise inherited from "Manufacturer 1" class)?

Hoping for help, explanation or anything.

Shane.



Message Edited by shoneill on 11-14-2007 09:54 AM

Message Edited by shoneill on 11-14-2007 09:55 AM
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 1 of 4
(2,621 Views)
Come to think of it, it would be nice to have the class "Spectrometer" as shown above to also not be instantiated.

Is this a classic "Abstract" class question?

I'm relatively new to OOP, and I'm learning by doing....

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 2 of 4
(2,602 Views)
Shane,

I have not started working with OOP yet, so these comments are purely speculative.

Would it be better to always have a manufacturer class so that Model 1 and Model 2 would inherit from Manufacturer 0 (which might be a generic that could be used for any spectrometer that did not have siblings)?

Lynn
0 Kudos
Message 3 of 4
(2,587 Views)
Thanks for taking time to answer Lynn,

This wouldn't solve the problem.  The problem as I see it is that the basic functions and data defined in the base class "Spectrometer" propagate to ALL child entities.  This is good, unless I want one or two children NOT to be creatable (which is the case here).

The problem is that "Manufacturer 1" inherits from "Spectrometer" but is in itself an abstract class (i.e. shouldn't be instantiated).  Each of Model 3 and Model 4 inherit from "Manufacturer 1", and hence also from "Spectrometer".  I'd just like to skip the "Manufacturer 1" step in my Dynamic Dispatch for the "open" function.

If I added another Manufacturer 0, then this would only serve to introduce another class which I don't want instantiated, but which I can't stop.

I kind of solved the problem by editing the Icon of the Object constants which should not be created to clearly indicate that they're not valid.  I'm hoping the users of the software are clever enough to realise what this means......



Time will tell if this is appropriate....

Shane.


Message Edited by shoneill on 11-14-2007 04:18 PM

Message Edited by shoneill on 11-14-2007 04:20 PM
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 4 of 4
(2,573 Views)