04-13-2010 02:47 AM - edited 04-13-2010 02:48 AM
Hi there,
I have successfully built a .NET interop assembly (using LV 2009) and called up the function I exported into that assembly (really just a dll) from within a .NET Csharp (C#) project.
In the same way that a LabVIEW built ActiveX EXE/DLL server can export properties and methods of all the controls and indicators in a vi, I would now like to export properties and methods of controls and indicators into the .NET interop assembly. Is this at all possible ? Or must I continue to use an ActiveX server to create unmanaged code (from .NET's perspective) for which I must write a RCW ?
rgds
04-13-2010 05:46 PM
Hi Peter,
To clarify your question, let's say you have VI that you have built into a .NET interop assembly and one of the inputs is an interger value. In LabVIEW this input would be connected to a numeric control and there are properties (such as color, value, etc.) and methods (such as reinitialize to default). Are you asking whether you can import access these same properties and methods in.NET C#? If so, the short answer is no. Is there a particular property or method that you would like to use? If you have Measurement Studio, you could find similar indicators and controls for .NET that you can access the properties and methods for.
04-13-2010 06:18 PM
rgds
O54E wrote:Hi Peter,
To clarify your question, let's say you have VI that you have built into a .NET interop assembly and one of the inputs is an interger value. In LabVIEW this input would be connected to a numeric control and there are properties (such as color, value, etc.) and methods (such as reinitialize to default). Are you asking whether you can import access these same properties and methods in.NET C#?
Yes I am
If so, the short answer is no.
Thats a shame. Is this just because NI haven't yet implemented this in LV. or is there a technical reason why this can't happen ?
Is there a particular property or method that you would like to use?
I would like to access the value properties of controls and indicators. Basically I need to programatically run a vi and while it is running programatically interact with its FP by toggling booleans, setting and reading values etc.
If you have Measurement Studio, you could find similar indicators and controls for .NET that you can access the properties and methods for.
We'd purchase it if necessary. Does MS allow us to create a .NET interop assembly that exports properties and methods of controls and indicators ? The entire project has been written in LV, so I'd rather not undertake large changes to incorporate MS. I was basically hoping not to have to use the 'outdated' ActiveX EXE server solution which .NET sees as unmanaged code.
04-14-2010 06:01 PM
04-14-2010 07:01 PM
Hi Mike,
The example you gave will solve my problem in a similar manner, however my intention is to avoid using ActiveX (server) which is an outdated technology from .NET's perspective. LV 2009 only exports the vi function into the .NET interop assembly, it doesn't export properties and methods of the vis, as does Measurement Studio (apparently).
rgds
04-15-2010 01:42 AM - edited 04-15-2010 01:44 AM
I personally doubt that exporting the LabVIEW object model as .Net Server would be a feasable project. They are from the ground up very different things. Since LabVIEW is not build on .Net but uses its own completely platform independant object model and implementation, exporting this model to .Net would leave many things to desire. You could not easily combine those objects with other .Net objects since they are not derived from basic system classes and such.
And wrapping up every object type in LabVIEW into an according .Net class would be a very big and probably boring project, with little chances to make it match up completely.
04-15-2010 01:51 AM
Thanks Ralph. Perhaps if NI only exported the controls as is done with Measurement Studio, and possibly even Events too. LabVIEW is good at handling event (calllbacks) from .NET and ActiveX, but unfortunately it doesn't work the other way around (i.e. for LV to fire an ActiveX or .NET event able to be serviced by another app.)
Anyway, I think I'll have to go back to using the ActiveX EXE server method for now.
rgds