05-15-2012 02:51 PM
In the documentation for the Array class. ![]()
Since the Array class is abstract, there is no public constructor, by definition. Thus, a static method is provided to create an instance of it. In fact, the documentation states:
Unlike most classes, Array provides the CreateInstance method, instead of public constructors, to allow for late bound access.
P.S. Please mark the correct response as the actual solution so that others running across this know what the solution was, rather than your "OK" message. You can unmark a post as the solution using the "Options" menu right above the message and to the right.
04-15-2016 04:42 AM
I've more or less the same problem, but reading an array of array. I'm using a .NET dll called CEBRA from INCA and the code I've developed so far is:
As you can see when I try to use the output of the GetFloatPhysValue method I get a LabVIEW error:
"Compile Error. report this problem.... Creating array of array".
Have you never seen this problem?
Do you know a possible workaround?
The CEBRA help for this method si:
Thank you,
Paolo.
04-18-2016 09:09 AM
Hi Paolo,
In LabVIEW, you cannot create an array of arrays. You can create multidimensional arrays or clusters of arrays, but you cannot create an array of arrays. See the "Restrictions" section of this link:
http://zone.ni.com/reference/en-XX/help/371361L-01/lvconcepts/grouping_data_with/
I do not have any experience working with this dll from INCA, so I'm not sure what a workaround would be. But if you can somehow get the output into a different form than "array of array," that would be a good start.
04-18-2018 03:53 AM - edited 04-18-2018 03:57 AM
Adding this as it's the top result when I do a Google search for labview .net array
The following also works for simple data types (and is probably more efficient).
Let LabVIEW do the work.
Example using strings.
04-18-2018 04:18 AM
One thing you shouldn't forget is to close every single .Net Refnum that you create, explicitly through the To .Net Object.vi as well as implicitly by the property nodes and/or methods that return a refnum. Those refnums consume memory for the refnum itself as well as they keep the underlying .Net Object alive.
For this simple code you won't see any effect as LabVIEW closes any refnums automatically as soon as your top level VI in whose hierarchy they were created goes into idle mode but if you build this into VIs that you call from an application that is supposed to work for days without restart it will eat up into your memory over time.
04-18-2018 04:48 AM - edited 04-18-2018 04:49 AM
It was intended as a quick example, but you're right I should be closing them in the example (and always do this in my programs). https://forums.ni.com/t5/LabVIEW/NET-Explicitly-closing-references-for-each-property-invoke-node/m-p... 🙂
For completeness, a better example is shown below: