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 AMMessage Edited by shoneill on
11-14-2007 09:55 AM
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)