01-08-2016 10:07 AM - edited 01-08-2016 10:10 AM
Not a long time C# or dotnet user.
Looked through most of the docs on using .net inLabVIEW, like community page for .net and all it's links. Looked over the examples that ship. Don't see a good article or thread discussing interfaces (see link below).
I'm using two dotnet assemblies (.dll) that have classes that I can instantiate using constructors. However, there are also a lot of interface objects that have to be used. What is the right method to using interfaces in an assembly.
These interfaces are supposed to be used to manipulate and get and set data from the .net controls that can be instantiated on the front panel.
Here is my experience: I can't use a constructor to create a reference to an interface object, but I can create a front panel .net refnum to get a reference to an interface object. However if I try to use the methods and properties directly from the FP refnum I get "null" errors kicked out (System.ArgumentNullException).
What is going on here under the hood, is this the correct way in LabVIEW to use interface objects in an assembly? (see diagram below)
I am assuming that the object ref that I cast to the interface ref type should (must?) be an object that the interface is supposed to "operate on" . Or said another way, taking a leap here, I think the class that I instantiate with a constructor has to have the implementation of the interface inside itself. So labVIEW wants you to cast your object to the refnum of the interface in order to expose the properties and methods of the interface, as developed by the class object. DOes this sound about right?
I did rely a bit on this one thread, but it was a bit short on detail. C# Interface exchange
Here is an image. The Blue is the dotnet refnum that is set to select the interface class, and the red is the class that "should" have this interface implemented. If I try to get to these properties and methods directly from the red class, they are not in the node. But if I cast it to the Blue they are available. If I just take the blue ref directly and look at its props and methods, I get the Null error.
01-08-2016 12:00 PM
I don't have a .NET interface DLL handy to check and test, but I think you have it mostly right except that maybe instead of using the variant conversion VI, do the "to more specific class" and "to more generic class" VIs work on those wires to change the types around?:
It sounds like it works, and you're just making sure that you made it work in the proper fashion?
01-08-2016 01:33 PM
I would say FP object is not calling a constructor with proper initialization of the object.
Looks like a bug, probably dll. If trivial LV examples with system .Net control work, may be the dll uses specific unsupported features.
Can it be labVIEW - .NET versions compatibility issue? May be updating .NET or downgrading .NET to match old LabVIEW version will help.
I have worked with .NET, front panel initialized (Thorlabs MG17 motor control, others), a lot of constructors on block diagram ones, did not need to typecast one to another to make them work.
>> So labVIEW wants you to cast your object to the refnum of the interface in order to expose the properties and methods of the interface, as developed by the class object. DOes this sound about right?
For LabVIEW these are 2 different types of objects. For each type dll has different sets of properties and methods you can set externally. I do not know what is real relation between these 2 types - may FP type just exposes interfaces to the parent type (from private to public), that is why these properties work.
01-12-2016 07:14 AM
Your findings sound about right. An interface is simply a definition not an implementation of an object. So if you create a refnum with the right interface type it does know what this interface can provide, but it does not have an actual object instance to operate on -> hence the NULL object error.
LabVIEW needs an actual object instance to do anything useful with property and method nodes as otherwise there is no object in memory to query anything from. If an object implements multiple interfaces (often called multiple inheritance in OOP) then you have to tell LabVIEW to convert the current object interface into the newly wanted interface. This is usually done with the To More Specific Class, but Variant to Data seems to work in your case too, which I'm not sure works on all .Net classes. It's probably more of a side effect of some LabVIEW internal implementation detail than anything specifically intended.
So in general what you found is the right way to go about this.