02-28-2013 04:02 PM
I am trying to repeat a C# DLL function call in LabVIEW (see below). I am struggling with the first argument of the function. The first argument is System.CollectionsGeneric.IEnumerable <app_object>. I think I am struggline in implementing two C# concepts in labview, and they are array of objects and enumerable. Can someone help? thanks!
C# DLL function call
connection.read(new ReadObject[] {app_object}, out stat)
03-01-2013 01:35 PM
I think you need to create ReadObject with a specific contructor from the API. It occurs to me, that you are trying to do some reading on some device, so that the ReadObject is the object, in which all the connection data is stored. Try to look for some function that can construct it and fill it with proper data, these should have some more standard terminals.
03-04-2013 02:31 AM - edited 03-04-2013 02:33 AM
LabVIEW .Net does not and can not support object constructors and methods that use Generics (the <anything> in your declaration). See here for more details and possible workarounds which would usually mean to write a wrapper assembly that exports explicit constructors and methods instead and then invokes the Generic ones.
03-04-2013 01:32 PM
Can you elaborate on that? Which part of the call is the problem? What did you mean by <anything> in my declaration? I need to know more about the problem, so that I can ask the .NET developer to help me. Thanks!
03-04-2013 04:08 PM - edited 03-04-2013 04:12 PM
I meant specifically the use of the pointy brackets <> in System.CollectionsGeneric.IEnumerable <app_object> which is the syntax used for Generic types. Basically LabVIEW can not construct objects of such types, or call methods that use such types. The reason is rather involved but lies in the fact that Generics are very difficult to support in a strictly typed language like LabVIEW in combination with the autogenerated code that LabVIEW creates from the interface description of the assembly.
Support for such datatypes would require the ability to configure somehow the type of the Generics at edit time, which would mean a rather complicated configuration dialog for those nodes, where people would have to configure things, most wouldn't understand.
Instead your .Net guy should write a wrapper assembly that exposes .Net interfaces with explicit datatypes instead of the Generics.
03-04-2013 04:58 PM
Thanks for your help. Where can I read more about this? Would a basic .NET book talks about this?
03-04-2013 09:33 PM - edited 03-04-2013 09:42 PM
There are several online resources specifically around the .Net 'environment'; I would strongly recommend reading them to a basic level if you plan to integrate other assemblies in the future. You should also get your .Net developer to look over the link Rolf posted to make it easier to communicate the problem.
We typically only provide strictly-typed members to external clients as Rolf suggested.
03-11-2013 11:32 AM
The developer said I can use an array (T[] ) as an argument where an IEnumerable<T> is expected. Can we do that in LabVIEW? Wouldn't there be a type conflict? If we can do that in LabVIEW, how? He also said I can create a wrapper. How do I even get started, since I am not a .NET person.
03-11-2013 11:32 AM
Can you help me? I made another post in the same thread. Thanks!
03-11-2013 11:35 AM - edited 03-11-2013 11:40 AM
Well I'm sure it's possible with Reflection and what else but not out of the box. The problem is that LabVIEW extracts the datatypes of all parameters from the embedded typelibrary in the assembly and doesn't allow to configure them differently. Either LabVIEW can understand and support the parameter type automatically or not at all.
Generics are specifically a feature that is prohibited since otherwise the automatic type library interface would have to be amended with a configuration dialog to allow configuring a specific type for Generics and possibly other types and that would get a rather complicated dialog that only diehard .Net programmers could possibly understand. But those people can much easier create a wrapper library instead. For those for whom creating a wrapper library is to demanding they wouldn't possibly have a chance to understand and configure that dialog properly.