.NET ArrayList into LabVIEW

[Joe_Gerhardstein]

I am trying to get a .NET arrayList into LabVIEW. The situation is somewhat complex, but goes as follows:

We have a .NET control that has been wrapped into an ActiveX control in VB. I can drop the ActiveX control on the front panel, then we have one property for the control that passes out the reference to the .NET control (via a Property Node). From here, we have a method in the .NET control that passes out an arrayList reference (from the mscorlib.dll System.Collections). This arrayList reference, however, appears to be completely unusable in LabVIEW (e.g., when I hook it up to a property node or invoke node, there are no properties or methods). Other reference we have passed out using the same method have worked fine (e.g., if we pass out an object array or string array, this works).

I have tried type-casting to various things (including valid arrayList references created in LabVIEW), and tried using the "to more specific class" or "to more generic classes". In all cases, I get an Error 1 ("Input Parameter is Invalid") referring to the arrayList reference.


Any thoughts?

[Gorg]

Hmm. LabVIEW probably isn't able to find the mscorlib.dll assembly. You've probably noticed that it's not in the GAC. Go to Tools >> Advanced >> .NET Assembly References... and add C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll and see if you have better luck.

[Joe_Gerhardstein]

You were right that it was not in the .NET Assembly References, but adding it does not help (same problems accessing the reference).

We ran the gacutil to find what is actually registered, and noticed that the mscorlib.dll is registered twice:

mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Custom=5a00410050002d004e0035002e0031002d003800460053002d00300030003000380031003000320035000000
mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Custom=5a00410050002d004e0035002e0031002d0038004600440053002d00300030003400300042003900350036000000


Do you know if this is an issue? Most of the frameworks were registered twice.


Joe

[Gorg]

mscorlib and many other assemblies are listed twice in the GAC on my machine as well. My googling hasn't turned up anything about it. All I can say is that the GAC is a strange and mysterious beast.

[Lycangeek]

Don't worry about having two instances of the framework in the GAC - that is to be expected if you have both the 1.0 and 1.1 frameworks installed. The GAC is just a global repository for assemblies that are going to be used by multiple applications - aka the framework, but 3rd party assemblies also go in there. For example, the NI MeasurementStudio assemblies are put into the GAC.

I am very curious to know what is getting messed up by the .NET reference. Is there anyway you can post up or email to me (bloggingbrian@gmail.com) the .NET assembly and ActiveX control wrapper?

[Joe_Gerhardstein]

Brian:

Do you have Visual Studio .NET 2003 and Visual Studio 6 for VB? We are somewhat close to a deadline on another part of the project, so I am having trouble getting my .NET counterpart to jump at my every whim. However, I will try to organize a package I can get to you tomorrow (Friday).

Can we upload to the NI FTP server? Our email tends to strip most/all attachments.


Joe

[Lycangeek]

I don't have VB6 installed but I do have VS.NET 2003. However, all I should need are the DLLs themselves, assuming the ActiveX wrapper supports regsvr32.

I'm not sure how to get access to the ftp site (that is typically used by support and I'm in development...I can try to track it down). However, I've found that if you zip up the files, rename the zip to something else (like piz) and then attach it, it gets through most of the time. Give that a try.

[Joe_Gerhardstein]

Okay -- code is in the mail. Let me know if you need anything else to try it out.


Joe

[Joe_Gerhardstein]

Quick update on progress we have had today:

First, if we set up a .NET .dll and try to access an arrayList from it, there are no problems (e.g., direct access to a .NET object is fine). We can read and write elements to the arrayList. If we do the VB ActiveX wrapper around the .NET control, then we can read/write primitive data types (I32, string, etc.), but no complex types (arrayList).

Second, we verified that the arrayList pointer we are passing into LabVIEW is a valid pointer in two ways: 1) in LabVIEW, if we cast the pointer to a Variant and display it as an indicator, we get a non-zero number that looks like a reasonable memory pointer; 2) if we pass the pointer into LabVIEW, then back into VB, VB can access the arrayList with the returned pointer (hence the pointer is not corrupted by LabVIEW or set as a null pointer).

Third, we did find a non-optimal workaround. This involves the following steps: a) create an empty ActiveX container on the front panel of LabVIEW; b) creating the .NET object through a .dll (.NET Assembly) call; c) obtain the window handle from the ActiveX object (through an invoke node); d) set the parent window handle for the .NET object as the ActiveX object (through an invoke node); e) call the Show method on the .NET control (through an invoke node). This paints the .NET control into the ActiveX control. The non-optimal features of this are 1) you cannot see the .NET control until the program is run, so screen layout is not particularly easy; 2) when the LabVIEW application exits, the .NET control dissapears (so any displays or information in the .NET control is lost); 3) from a usability standpoint, now instead of just providing a pallet of ActiveX controls to my customer that they can just drag to the front panel, I need to provide multi-step instructions on creating a control (we are using LabVIEW for its simplicity, which this solution is not) that has no positive feedback until runtime.

[Lycangeek]

My head hurt reading your workaround. That tells me we need something better 🙂

When LV is working with references (such as ActiveX or .NET), it keeps some extra information about the reference around. This is why a refnum is not a pointer to the object, but a magic structure inside LV that holds key information. This allows us to do all the various LV magic as the refnum is wired around or when the program executes, without having to ask the OS or jump into the CLR constantly.

My guess is that something in the multi-layered extraction of the ArrayList is confusing LV and the internal structure either has incorrect or missing information. If you can get me the code, I can run it through the debug version of LV and try to figure out what it thinks it has.