When LabVIEW meets .NET - a (un)happy marriage (part 2) ?

[fransv1963]

While trying to access .NET functionality from LabVIEW 2011, I ran into a (second) problem.

The .NET assembly defines its own DoubleComplex value type.

When using .NET/Link in Mathematica (from Wolfram research) to invoke .NET functionality from Mathematica, it is possible to define the class or struct in .NET which represents the complex type. From that moment on, Mathematica takes care of mapping .NET complex values, arrays or matrices onto their equivalent in Mathematica (and vice versa). The .NET class or struct simply needs to adhere to a few simple rules such as containing a Re and Im property.

As far as I can see, there is no such support in LabVIEW which unfortunately makes me conclude that one has to split a complex value, array or matrix into its real and imaginary part at the .NET side in order to reconstruct the complex value, array or matrix at the LabVIEW side (and vice versa). This in not really an elegant solution and also requires unnecessary copying.

So, is there anyone out there who knows if there is a smart(er) way to deal with this problem ?

Thanks again to anyone who read my question and an extra thank you to anyone who provides a relevant answer or comment 

[tyk007]

I would be interested in an alternative way myself. Thus far I have had to limit my return values to one of the LabVIEW data types.

If I have understood what you mean correctly, you can do this in Labview - but you have to it youself as you suggested ie. define a VI wrapper that returns a Labview type (such as a cluster with Re, Im elements) based on known Labview data types returned by your .Net assembly. This sounds like what Mathematica is doing for you, albeit "auto-magically".

What you really want is for Labview to automatically generate a cluster with the appropriate definition based on raw value types in the class, which is the simplest way of transmitting struct like information. Yeah one could say there is definitely un-necessary memory allocation but that happens a lot in Labview and is also happening behind the scenes in Mathematica in your description anyway.

Please, if anyone has an alternative speak up 

[smercurio_fc]

The issue you're describing isn't endemic to LabVIEW. You'd have the same exact "problem" if you were using that assembly in Visual Studio. If I have, for example, a C# program that generates some data, in order for me to "stuff it" into the DoubleComplex type, I'd need to call the constructor of it for each of my data points. Presumably the type has a constructor where you provide the real and imaginary parts, as opposed to creating an object of that class and then using properties to set the real and imaginary parts. There is no automatic conversion mechanism for custom data types. Mathematica does this and it seems to be a very convenient mechanism. However, that's just Mathematica doing it.

[fransv1963]

I tend to agree that all is caused by the fact that - for one or another obscure reason (at least IMHO) - the complex type was never treated at the same level as int or double (i.e. as built-in types) and as such lacks interchangeability. So indeed it is not a specific LabVIEW problem, but given the fact that Mathematica has implemented an elegant way to deal with this, I wanted to make sure if there isn't something similar in LabVIEW.

Unless I incorrectly interprete your reply, IMHO there is no problem in Visual Studio as long as you continue to use the DoubleComplex assuming the .NET assembly provides sufficient functionality to use this DoubleComplex type.

[smercurio_fc]

---

Unless I incorrectly interprete your reply, IMHO there is no problem in Visual Studio as long as you continue to use the DoubleComplex assuming the .NET assembly provides sufficient functionality to use this DoubleComplex type.

---

As you say, as long as the .NET assembly provides sufficient functionality...