.net interop assemblies oddities

[PJM_JKI]

Cross-posted on LAVA

1st oddity: The documentation specify the following:

"Clusters and enumerations defined as type definitions or strict type definitions—LabVIEW uses the label of the type definition or strict type definition as the name of the .NET structure"

In reality I find that to be incorrect. Instead it used the typedef instance name. Am I missing something?

Note: I know I can rename it, but there are very good reason while I would love to have it worked as described in the documentation

2nd oddity: When a typdef is part of a class it does not show as such when call from a .net app.

For instance if I have the following in my LabVIEW project:

• A class is called shape
• A method in the class is called getBound
• A cluster typedef in the class is called Bound
• An interop build spec where the assembly namespace is LVInterop

Then when I call the resulting dll from c# I see:

• LVInterop.shape.getBound (yeah, getBound method is part of the shape class [as expected])

but I also see:

• LVInterop.Bound for the Bound typedef (?? how come the bound type is not part of the class ?? [I would expect LVInterop.shape.Bound])

Any feedback on these two oddities will be very welcome.

[netsirk]

Hi PJM_JKI,

On the subject of the first oddity, the “label” of a typedef actually refers to the instance - so the name of the .NET structure will refer to the specific instance of the typedef. If you're referring to the “name” of the typedef, the .NET structure does not take this on to preserve unique instances.

With regard to the second oddity, do the results differ when you use the LVInterop.shape.getBound command versus the LVInterop.Bound command?

Regards,

[PJM_JKI]

---

On the subject of the first oddity, the “label” of a typedef actually refers to the instance - so the name of the .NET structure will refer to the specific instance of the typedef. If you're referring to the “name” of the typedef, the .NET structure does not take this on to preserve unique instances.

---

ok, if using the label of the typedef instance is the intended behavior I will suggest that the documentation need to be updated because it clearly seem to indicate that the label of the type definition will be used (and not the one of the instance).

---

With regard to the second oddity, do the results differ when you use the LVInterop.shape.getBound command versus the LVInterop.Bound command?

---

    Well, the LVInterop.shape.getBound is a method of the class. the LVInterop.Bound is a type (which is in a class in LabVIEW but not in .net).

    Maybe looking at an example in c# will help clarify what I mean:

using System;
using LVInterop;  //This is our LVInterop dll

namespace testApplication
{
    class Shape
    {
       // assign variable
       LVInterop.Shape Rectangle; 
       LVInterop.Bound myBound; //This shoud be inside the class shape in .net as it is in LV and this should read LVInterop.Shape.Bound myBound
       
       //Call Shape class methods
       LVInterop.Shape.Constructor (out Rectangle); //Init/create the lvclass object
       LVInterop.Shape.GetBounds (Rectangle, out myBound); //call the GetBounds method
    }
} 

 Hopefully this does clarify things a bit.

In anycase, I appreciate the help.

PJM

[netsirk]

PJM,

When you define a type definition in LabVIEW, it creates a control file that is accessible to everything in the greater project file. Even if you only use this typedef within the Shape class, it is not exclusively linked to that class and therefore will be defined in .NET as a public type.

Regards,