Integrating .net UIs into Labview

[Michael Ludwig]

My company has developed a large piece of software (3000+ vis) in LV which it sells to a number of customers. Because a large part of the software is simply UIs that interact with a database, we are thinking of moving to VB.NET or C#.NET for most UIs and retaining LV only for the "test" screens that interface with instruments.

Of course, we cannot just re-write all the existing LV code into VB (etc.) at once, but need to gradually migrate towards less LV and more VB. What are your suggestions? Should we:

1. begin to replace VIs with calls to .NET dlls?

2. use containers to insert the .NET UIs into a LV wrapper?

3. use VB to call LV exes?  

or is the whole approach wrong-headed, in which case what other solutions would you propose for writing nice, efficient Db interfaces (I have never found LV to be very good at that)?

[smercurio_fc]

---

Michael Ludwig wrote: 

in which case what other solutions would you propose for writing nice, efficient Db interfaces (I have never found LV to be very good at that)?

---

Neither have I. LabVIEW does have the Database Toolkit (or whatever the heck it's being called nowadays), but as far as UI it pales in comparison to being able to use something like the WinGrid from Infragistics, which is what I use (albeit an older version) for an internal app that I wrote in C#.

As for your options, it sounds like your main app would be on the VB.NET/C# side, with the test screens being called out. If that's the case, I don't think option (1) is going to buy you much. You could actually reverse that and compile the LabVIEW code into a DLL that you call from .NET. However, this would be treated as unmanaged code in .NET. 

I wouldn't recommend trying to use containers to insert .NET UIs. That's just asking for trouble. 

You could compile the LabVIEW code into an executable and simply call it from .NET. If there is no need to pass data back and forth then this is the simplest approach. Even if you have to pass data you can use mechanisms to do this, such as files, or communication protocols. You may be able to use streams, but the stream would need to be created by one process and used by the other. 

Have you considered using Measurement Studio? That's another possibility.