Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
I am having trouble with the implementation of the eMail ActiveX in VDF.
I have installed the Chilkat msi file and unzipped this set of PKG files into the “C:Program FilesVisual DataFlex 17.0Pkg” folder.
I have also tried copying the DLL to be in the local software program folder – same error
Then I manually registered the DLL – again, same error:
Unable to instantiate COM object. ActiveX component may not be properly installed or registered. Error code: 0x80040154
Before answering the question, it's important to have a basic understanding of ActiveX DLL registration. In a nutshell, programs that instantiate an ActiveX object do so by some sort of "CreateObject" statement, passing a name such as "Chilkat.Email" to the CreateObject statement/function. The syntax may vary amongst different programming languages, but they are all the same in that a name is passed to some sort of "create object" call.
To instantiate an object, the CreateObject must lookup the path to the DLL in the registry. This is the point of ActiveX registration -- to create a key in the registry such that you can lookup by name ("Chilkat.Email") to get a path to the DLL, such as C:/blah/blah/blah/ChilkatEmail2.dll. If the name is found and the DLL is located at the indicated path, it is loaded and dynamically linked into the address space of the application.
With each new version of Windows, Microsoft has made this simple task of adding a few registry keys to associate a name with a path more and more obtuse, difficult, laden with pitfalls. On top of it, the error messages are always to general to be helpful, with obscure error codes that are meaningless.
There's one caveat, and this has to do with 32-bit vs. 64-bit. A DLL is binary object code that is linked at runtime into the address space of the application process. If the application is compiled for 64-bit then it is running as a 64-bit process and it uses memory addresses are 64-bits. It is only possible to dynamically link object code (i.e. DLL's) that have also been compiled for 64-bit. The same goes for 32-bit apps: they can only load DLL's that have been compiled for 32-bit.
On a 64-bit Windows system, it is possible to run both 32-bit and 64-bit applications. If the registry contains an entry that maps the name ("Chilkat.Email") to the path of the DLL file, then how can it satisfy both 32-bit and 64-bit apps? (Because two separate DLL's are needed -- one compiled for 32-bit and one compiled for 64-bit.) The answer is that a 64-bit Windows system has two entirely separate registries: one for 32-bit and one for 64-bit.
One must use the 32-bit registry when registering a 32-bit DLL, and the 64-bit registry must be used for registering a 64-bit DLL. When an application runs, it will by-default use the registry that matches its address space. 32-bit apps will always use the 32-bit registry, and 64-bit apps will always use the 64-bit registry.
It would be an error if the entries in the 32-bit registry pointed to a 64-bit DLL, or if the entries in the 64-bit registry pointed to the 32-bit DLL. One must be very careful to update the correct registry so that it points to the correct DLL.
The solution to the problem (Error code 0x80040154) is to re-register the DLL following the instructions at this Chilkat blog post for registering a DLL very carefully.
First, you must know whether your app is running as a 32-bit process or 64-bit process. If 32-bit, you must register the 32-bit DLL in the 32-bit registry. Likewise for 64-bit. If you don't know whether your app is 32-bit or 64-bit, you could download each of the 32-bit and 64-bit Chilkat DLL's and register each. That way, regardless of 32-bit or 64-bit, your app can resolve from the name ("Chilkat.Email") to the DLL path correctly.
A note regarding Chilkat ActiveX DLLs: The Chilkat Active DLL's are plain-vanilla, standard, self-registering ActiveX COM DLL's. There is nothing unusual about them, and with respect to registration, nothing has changed in 10 years. Problems with ActiveX object instantiation are always due to the registration being flubbed in some way (no thanks to Microsoft for making it so difficult) or perhaps the ActiveX DLL is placed in an untrusted shared/remotely mounted filesystem and there's a permissions issue.