Error with executable using ActiveX object in ver 7

[CrisEst]

I have a top-level VI (version 7 in WindowsXP) that contains an ActiveX control. This ActiveX object further calls several DLL’s, one of which controls the serial port. SubVIs in the top-level VI call this ActiveX object via Invoke Node and Property Node. Everything works in the LabVIEW development environment. The ActiveX object is registered using the “regsvr32” command and is made with Visual C++.

When I try to build an application of the top-level VI, the executable doesn’t work (giving the error “The server threw an exception.” Error -2147417851). I’ve narrowed the problem down to the ActiveX calls. I’ve tried embedding the ActiveX object and the DLL’s in the executable as support files. I’ve also tried changing the Execution property of the top-level VI from “same as caller” (default) to “standard” (no change) and “user interface” (crashes executable). The application setting “Enable ActiveX server” is checked. I still get the error. Any suggestions?

[Chris_Cilino]

CrisEst,

I have a couple of things for you to try:

1. Do you notice this behavior with other ActiveX controls? Try to build a blank vi with another ActiveX control and see if it gives you the same error.

2. Try running your exe with LabVIEW open.

3. Try running your exe with .NET open.

Let us know what you find.

Chris C

Applications Engineering

National Instruments

[CrisEst]

Chris C,

I was about to try your suggestion #1 but ran across a few postings on here that mentioned the sensitivity of the path(s) of ActiveX objects and DLLs with executables. So I tried running the executable from the same folder as the ActiveX object and DLLs, and now it all works. The top-level VI points to the object, and I had kept the path of the object and DLLs fixed (same) on the target PC's, but I guess this is not enough. I appreciate your suggestions.

Regards,
Cris

[Chris_Cilino]

Hey Cris,

Great catch! Would you be willing to post the links you found that helped to solve your problem? Thanks!

Chris C

[CrisEst]

Chris C,

I searched the NI forums and Knowledge Base and finally the LAVA forum, and I turned up info on the sensitivity of DLL paths in the LAVA forum for Application Builders, etc. Then I went back to NI forums and searched for "path executable dll" and found a thread titled "Where LV searches for DLLs". The response by "rolfk" provided the info that got me on the right path. See http://forums.ni.com/ni/board/message?board.id=170&message.id=156621&query.id=32143#M156621. I still don't know why the (fixed) primary path (as specified by the ActiveX container control) didn't work in the first place, but the fix for me is easily acceptable (executable in same folder as object/DLLs).

Regards,
Cris

[Doctor John]

Hi Chris and Cris --

I have almost exactly the same issue with an application that I'm building...  the LV8 (or LV7.1) code using a third party active-x object works fine till it is built into an executable.  (see message:  http://forums.ni.com/ni/board/message?board.id=170&message.id=179673).  The active-x object in question accesses a host of other dll's as it is setting up communication parameters for a spectrometer.

I did try your solution of executing from the same directory as the active-x object.  It changed the result a bit although it still didn't work correctly. 

Did you ever figure out the root cause of this problem?  Unfortunately, your solution of running from the same directory as the dll isn't possible for me.

Sincerely,

John

[CrisEst]

John,

I don't know the root cause of why my solution worked (for my situation). Since it was good enough for me, I didn't pursue it further.

Regards,
Cris

[Lycangeek]

I'm not exactly sure what is going wrong, but I have some information that might help. As has been mentioned in some of the referenced posts, Windows has completely different ways of finding DLLs depending on the technology being used.

When dealing with a COM library, LabVIEW calls CoCreateInstance - a COM method provided by Microsoft to create the object. This method looks in the registery to find the absolute path to the ActiveX DLL. Thus it doesn't matter where your DLL (versus your LV application) is located.

HOWEVER - If that ActiveX DLL then uses other DLLs via a normal C interface, the rules change. If the ActiveX DLL just links normally (using a .LIB) with these dependent DLLs, then that ActiveX DLL relies on the PATH environment variable to find the DLLs (which typically includes the current directory - and is probably how Chris' app started working). The ActiveX DLL can also call LoadLibrary() directly, and thus can provide an absolute or relative path - raising all sorts of possibilities.

ACTION ITEM

Here is my suggestion. Go to www.sysinternals.com and download the File Monitor (http://www.sysinternals.com/Utilities/Filemon.html). Set the filter on the monitor to the name of the EXE (either LabVIEW.exe or your built application). Then run the app. You'll see a lot of entries, but you can then search for the various DLLs in question. Don't be surprised to see FILE_NOT_FOUND errors, you'll get that as Windows probes around the various directories trying to find the DLLs.

You can do this in both LV and your built app and see the difference in how it searches. That should give you some idea as to what is going wrong. Please feel free to post a follow-up with more questions once you've done this.

[Doctor John]

Seems strange to reply to my own original post but here is a follow-up...

I contacted the vendor of the active-x library that I was using and they fixed me right up.  As it turns out, this library was setup to let the Labview Environment use it but not let it be used by an Executable.  I'm not sure why they did that.  As soon as I asked, they supplied me with a library that fixed the problem.

Thanks for all that helped me with this.