nested typdefs used in LabVIEW .net interop assembly not being labeled correctly

[smurray]

Hi All,



While I'm waiting on a response from a LabVIEW AE, I thought I would post this question to a broader audience.  So, here goes:  I'm trying to use a LabVIEW .net interop assembly, with exported VIs whose inputs/outputs have typedefs.  My understanding is that LabVIEW is supposed to generate equivalent .net types _using the typedef label as the name_.  This seems to work for _non-nested_ typedefs, but doesn't work for typedefs that are nested.  For example, given a typedef'ed enum with a label 'myEnum', if the VI I'm exporting to a .net assembly has an array of myEnum as an input called myInput, the manifest says that the VI has an input of myInput (correct), which is of type LVEnum_1, not an array of myEnum (not correct based on my understanding and the documentation).  The same thing happens with typedefs inside a typedef'ed cluster.  For example, if I have myEnum (again, a typedef itself) inside a myCluster typedef, and this is used as an input to an exported VI, the manifest says that the input is of type myCluster (correct), but myCluster in turn has an field of type LVEnum_1 (not correct).  Is this expected behavior, i.e. is LabVIEW not capable of correctly labeling exported arrays of typedefs and/or typedef'ed clusters with typedefs inside them?



Thanks,

Steve

[instrumento]

Same problem here for a co-worker.  As there hasn't been a response I'm opening a ticket with NI too..

[The_Hunt]

Hello Everyone, 

I am posting the resolution to this issue so that other users can come across it as well. 

Problem:

When a reference control for a calling statement is created, LabVIEW is able to parse through the names correctly, but the Property Node ends up with a different name "LVCluster_1", as opposed to "ThisCluster". 

Solution:

Use a Constructor Node instead and select "ThisCluster" as the object. Now, when the propery/invoke nodes are created off of this reference, the appropriate naming convention now follows.