Browsing for ActiveX

I've seen this confusion several times, so I thought I'd do some explaining of what is going on with ActiveX support in LabVIEW. I'll get the quick version for those with A.D.D., and then go into the details.

Quick Version: Browsing for an ActiveX library is really browsing for the type library (TypeLib). Thus it has no effect on the locating of the component at runtime.

Okay, let's walk through this.

First issue: ActiveX vs. COM support

When we say ActiveX support in LabVIEW, we're really talking about COM support. ActiveX is simply COM with a bunch of predefined interfaces and UI pieces. LabVIEW does support ActiveX in that we're a container, thus we can host an ActiveX control on our front panels. However, when you're programming it with invoke and property nodes, it's any COM component.

Second issue: Type libraries

In the beginning, there were DLLs that you could call from LabVIEW. But DLLs don't share information about their programming interface, other than the names of the methods they expose. The DLL says nothing about the parameters it takes. To get this information, you must look at their header (.h) file (NOTE: LabVIEW 8.20 does have an import wizard that'll read the header file for you and create VIs to call the methods automatically!)

Realizing this limitation, COM supports something known as Type Libraries (typelib). These are independent binary files that fully describe the methods so that any environment can know exactly what is exposed. Generally these files are then bundled into the DLL containing the code, so often it's only one file. However, sometimes they are separate (such as LabVIEW's type library in <labview>/resource/labview.tlb.

Generally, type libraries are only provided for COM interfaces. However, if you program your DLL with LabWindows/CVI, you can create C DLLs with type libraries. I don't know of another C compiler that does that...it's pretty nice.

Back to the story...These type libraries provide so much support for programmers, that both Java and .NET incorporated the idea into their systems. Unlike old-style DLLs, Java classes (.class) and .NET assemblies (.dll) have full  type-library-like information automatically (fyi - this kind of information is usually referred to as meta-data).

Third Issue: Creating a instance

When you actually run LabVIEW code that creates a COM component (calls Automation Open or displays the front panel container), we don't go looking for the DLL - we call into Windows (via a method known as CoCreateInstanceEx()). This is similar to .NET, where a subsystem known as Fusion is responsible for finding the assembly. COM's code looks in the registry for the location of the component's DLL and loads it.

Impact - You must register your COM component in order to call it from LabVIEW. This is key because you don't have to register it to write the VI!

Fourth Issue: The Confusion

This leads to the confusion. You drop down an Automation Open node, right click and say Select Class->Browse. You navigate to the DLL or TLB, select it and write your VI. But when you run it, it either can't find it or finds some other version (common problem for people writing their COM component and VI code at the same time).

When you browse, all you are doing is helping LabVIEW find the type library. This has no effect on runtime behavior.

Here endeth the lesson.