LabVIEW
'.NET Object to Variant.vi' Cannot Handle 2D Arrays
I think the main problem is you get a 2D array of Object OR a scalar Object.
LabVIEW supports Int[,], Double[,] etc, but although each object is returned as a variant, it doesn't convert arrays of objects.
I think you 'd have to use the GetEnumerator and do it yourself. Of course this will be dreadfully slow in LabVIEW, so you might make a utility assembly to do it for you.
Search LabVIEW like a graph! 
@dkfire wrote:
You still have a floating close, that could close the Range reference before the .net to variant has read the value.
The "floating" close closes a reference to range, not the range object and certainty not the value2 object.
This shouldn't be a problem.
However, the reference to Value2 is never closed, which might (probably will) prevent the Value2 object and very likely the range object to be removed from memory.
The objects have a reference count, and they can\will get disposed when there are 0 open references to the object. The open Value2 reference will prevent the Value2 object form being garbage collected, but if Value2 internally has a reference to the range object, the range object won't be GC-ed either. This is a memory leak.
@aeastet wrote:
You are correct. It was painfully slow. Even sower that I expected. I can get the XML data and process it myself. I was hoping to find a way to get the range to work. That way Excel handles all of the merged cells, different data types, formulas, etc... like it does in Active X.
I usually make a utility assembly.
You don't need anything, .net has everything contained to compile C#... Or you can compile with the command line, but you might get the wrong .net version.
@aeastet wrote:
That way Excel handles all of the merged cells, different data types, formulas, etc... like it does in Active X.
Well the .Net Interop.Excel namespace is in fact simply a COM Interop wrapper around the Excel ActiveX Automation Server interface. That is also the reason that the actual .Net class interface is a VERY close mirroring of the ActiveX interface. The problem is that the LabVIEW .Net to Variant VI can convert a .Net Object into a compatible LabVIEW datatype but not an Object[,] into an according 2D array of compatible LabVIEW datatypes.
Basically the .Net Interop wrapper looses some datatype specification by wrapping things into generic .Net objects, that was more clear on the COM (ActiveX) side of things. Yes it's possible to discover that type information, if you know that you have to, but it's not a very likely thing to happen for native .Net interfaces.
Of course knowing that this .Net Interop.Excel interface really just is a wrapper around the Excel ActiveX Automation Server, which is a wrapper around the internal Excel object interface, one starts to wonder how much future proofness you get by targeting the .Net interface instead of more directly the ActiveX interface!
Supposedly Microsoft could decide to discontinue the ActiveX technology, except that half of Windows still operates on the underlaying COM technology which is the major building block for ActiveX. Your entire Windows explorer shell is one huge COM system. Nothing but really nothing would work in Explorer if not for COM. Many other technologies are also still build on top of COM, even though some of it is nowadays hidden behind .Net interfaces.
