LabVIEW
Labview .net DLL inheritance
@ViltBalint wrote:
Hi,
I try to work with a .NET DLL, which has been generated from Labview code (classes), and I would use the .NET DLL in Labview.
So I have two questions about usages/possibilities:
- Can I derive a Labview class from a .NET class?
- If I create a .net DLL which generated from object oriented Labview code, then will I lose the advantages of OOP?
- For example "A" LV class with foo() method and "B" with bar() method, B derived from A
- --> export the code to .net DLL
- --> instantiate .net B class and call bar() on instance (in Labview)
- --> create an .net invoke node from A.foo() and pass the B instance, which is of course works if I don't generate dll from LV code, but it seems to me if I create a dll, and LV wraps my classes into .net classes, then I will lose inheritance between .net classes, is it possible?
Thanks for any help,
Balint
LabVIEW .Net DLLs export only classes which are directly derived from the basic .Net Object class. You can not make an exported LabVIEW .Net class interface derive from other .Net classes.
And you can of course create a LabVIEW OOP wrapper around a .Net class but the two class interfaces are not directly compatible so you can not derive a .Net class from a LabVIEW class or vice versa.
Well you need to understand the principle on which you create a LabVIEW .Net assembly. Basically you start with a VI library with one or more VIs in there and each VI you export is a method of the resulting .Net class. There is no way to define a specific .Net ancestor for this new class you create, partly because the .Net inheritance works quite a bit different than how LabVIEW executes VIs and LabVIEW has its own completely different way of managing memory than .Net. So to bridge between the two environments is pretty troublesome and doing so over class inheritance would be a major investment with questionable outcome in terms of achievable performance and stability. In addition would the configuration dialog to create a .Net assembly from a LabVIEW library got magnitudes more complicated since there would have to be a mapping between the methods of the parent and the methods you define to be exported and you would have to hand configure a lot of that. So the two class interfaces between LabVIEW and .Net are simply not compatible at this time.
As to wrapping a .Net class into a LabVIEW class to be usable as a LabVIEW object class, that refers to what you would call composition in the OOP frameworks. Basically you create a new LabVIEW object class that internally calls the .Net object methods and properties and in the "constructor" for the LabVIEW class you call the .Net constructor for the .Net class and store the refnum in the LabVIEW private class data. Then for every .Net method or property you want to be accessible in the LabVIEW class, you create an according VI to call the according .Net node. Serious work and there isn't a fully automatic method to do that, so quite a bit of manual handwork, but it certainly can be done.
The important thing to know is that there is no inheritance whatsoever between LabVIEW classes and .Net classes. They both live in their own managed environment that needs to get properly translated on every call from one environment to the other very much like what you have to do manually when doing Interop calls to access Windows system APIs. LabVIEW does most of that Interop handling for you and that can in some parts mean that you can't translate things yourself easily. Class interfaces is one area where you simply don't have enough control from within LabVIEW to make it work across .Net Interop boundaries.
And honestly I do not think you do want that kind of control in LabVIEW. The implications would make Interop calls to Windows system APIs look trivial in comparison, and there are already not many people who can manage that properly.
