Error with executable using ActiveX object in ver 7

Question

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?

Answer 1

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.
Brian Tyler
http://detritus.blogs.com/lycangeek