I'm getting a "The procedure entrypoint ssSr192x__ssSr192drvssSrReset could no be located in the dynamic link library ssSR192x.dll" because the ActiveX instrument driver DLL doesn't have the function names in the export table.

[Jeff Fish]

Is there a way for my CVI project to reference the functions in the ActiveX without including the instrument .fp in the project?
Thanks much.

I'm confused on how CVI uses ActiveX components and hope someone can help.

I'm using an ActiveX driver from an instrument manufacturer and I use the .TLB to generate a .fp, .c, and .h file. If I register the .dll and load the .fp in my project, all is well. Unfortunately in my application the functions to control this instrument are in another DLL whose .lib I include in my CVI projec
t. Running the CVI project this way gives me "The procedure entrypoint ssSr192x__ssSr192drvssSrReset could no be located in the dynamic link library ssSR192x.dll" because the instrument function names aren't in the export table in the instrument DLL. Non-ActiveX DLLs have the export tables so everything works for them.

Program structure with non-ActiveX DLLs:

CVI project (.exe with common.lib in project list)
|
V
Common DLL (MeasDMM() with hp1234.lib in project list)
|
V
Instrument DLL (hp1234_measure())

Since I get a .c and .h file from the .TLB, I've tried recompiling the DLL (.dll and .lib produced) and the functions seem to work, but I get "Class not registered" errors unless I play games with the registry so I'm obviously violating numerous Microsoft rules!

Is there a way for my CVI project to reference the functions in the ActiveX without including the instrument .fp in the project? Thanks much.

Jeff Fish
Advisory Test Engineer
StorageTek

[Jeremiah Cox]

Hello Jeff,
Where were your getting the .lib file for the ActiveX DLL? Did you use the "hp1234"
ActiveX driver generated by the "Create ActiveX Automation Controller" CVI Tool to build a static library? If you open an include file and choose Options >> Generate DLL..., it will generate source code or a static import library to load the specified DLL and load functions specified in the include file (this only works if the functions are exported from a DLL). However, in the case of our ActiveX Automation Controllers, ActiveX calls are used to access a DLL. This means that you do not need an import library. You should be able to open the "hp1234" source file and click Options >> Create Object File. Simply #include "hp1234.h" and add "hp1234.obj" to your Common DLL project;
the .fp file is not necessary. If this does not answer your questions or if you experience further difficulty, please post further details on what you are doing and the errors that are being encountered ("play games with the registry" and "recompiling 'the' DLL" are a bit vague in this case).

Jeremiah
Applications Engineer
National Instruments
http://www.ni.com/ask

[Jeff Fish]

I used Tools->Create ActiveX Automation Controller and browsed for the device's .TLB file to create the .h, .c, .sub, .obj, and .fp files. I then recompiled the .c and .h into a DLL to get the .lib (which shouldn't be required but seemed to work). So according to your comments, I should be including the .obj file I generated from the .TLB. How is this different from including the .fp in the build of the Common DLL?

[Jeremiah Cox]

Hello Jeff,
If you include the .obj file in your project, then it will be statically linked into the executable. If you build a DLL, then put the static import library into your project, your executable will be dynamically linked to the DLL -- you will have to include the DLL with your executable when it is packaged or moved between machines. If you plan to just build one executable that uses an instrument, it is easier to statically link in the object file. If you may have multiple programs that make use of the same instrument driver, it is better to use the DLL (this saves both disk space and memory during program execution).

Jeremiah Cox
Applications Engineer
National Instruments
http://www.ni.com/ask