| Author |
Topic |
|
|
rowe2
4 Posts |
 Posted - 04 Oct 2002 : 09:00:43
|
I've implemented a generic, COM component. All the code has been generated by eVC (for test purposes). This means I've yet to add any additional code or functionality to the stubs for my method calls.
This skeleton component compiles, downloads and registers just fine, according to eVC.
Now, I would think that I would be able to use this component (create an instance and excercise the 'empty' methods) in an application without any additional effort. However, whenever I try to create an instance, I keep getting a REGDB_E_CLASSNOTREG (0x80040154) or 'class not registered' error. I'm I missing something, here? Am I missing some step, some additional requirement that is needed to register my component?
I do see that my component has entries in the Registry, so I don't understand what the issue is.
I guess that I'm just unaware of some additional step that is required. However, I am unable to determine what that is on my own. Any help or suggestions would be appreciated.
|
|
|
ctacke
877 Posts |
Posted - 06 Oct 2002 : 11:07:22
|
It sounds like you've done everything right, but the ATL wizard doesn't always build properly and the process isn't always straightforward. When you create a library the wizard always suffixes your library with "Lib" in the IDL (who knows why). I suggest checking to see if you've either appended "Lib" to the library name in the instance creation call or if you've removed "Lib" from the IDL.
i.e. If you created a library called MyComponent and an object in it called MyObject, by default it would end up as:
MyComponentLib.MyObject
I always modify the IDL after creating the library to remove the "Lib" because it doesn't show up in object browsers and causes a lot of confusion.
You can look at a basic, already-built COM object in this Forum Topic. |
 |
|
|
rowe2
4 Posts |
Posted - 07 Oct 2002 : 10:49:58
|
Unfortunately, this doesn't help.
Remember, I'm using eVC - I don't ever reference the library or use a string containing it's name, as I would with eVB. I use CoCreateInstance() and pass in a CLSID and an IID (which are GUIDs, not strings).
Also, the CLSID and IID that I reference are valid - i.e. defined - or else my link would fail.
I'll look around for other, possible ramifications from the appended, 'Lib' text, but am not hopeful. |
Edited by - rowe2 on 07 Oct 2002 11:41:17 |
|
|
|
ctacke
877 Posts |
Posted - 07 Oct 2002 : 11:52:39
|
I had assumed you were using CLSIDFromProgID to dynamically retrieve the CLSID based on the device's registry settings and therefore would have been using the library name. If not, then I agree - I doubt the "Lib" suffix naming "feature" of the wizard has any effect on you.
While I agree that the CLSID and IID must be defined or the link would fail, this doesn't mean that the values in the device registry are necessarily the same. As a case in point, I had a problem in the past where I modified the CLSID in the IDL due to a version/interface change of a library, but did not manually change the REG files. This caused a Class Not Registered error.
Have you tried stepping through the registration and the instantiation of the library to try to determine exactly where it's falling down? |
|
|
|
vtk100
40 Posts |
Posted - 24 Jul 2003 : 12:00:49
|
I have the same problem here.
I'can't CoCreateInstance my component dll object.
But i can with MSXML or other device included components.
Do we need to use ADSCOPY?
|
|
|
|
mburr
3 Posts |
Posted - 07 Aug 2003 : 11:18:19
|
I've run in to this sort of problem before, although not actually on an ADS system. In my case it was an ActiveX control using MFC, but at the bottom of it was a CoCreateInstance problem to which yours seems suspiciously similar. Please take a look at the following documentation we have on the subject. Although this note is focused on an ActiveX control I think it would apply to you as well. Don't know if it will help, but it's a shot. Good luck!
Mike Burr
Benson Medical Instruments
mburr@bensonmedical.com
The management of ActiveX controls under Windows CE may pose some subtle problems. Although the support provided by the API for COM objects is nominally complete and supposed to be identical to that of the desktop, as it turns out, a few adjustments need to be made. In particular, a problem is caused by the API function CoInitializeEx, which for unclear reasons does not accept the COINIT_APARTMENTTHREADED flag. The CoInitializeEx function is responsible for initializing the COM subsystem, and its COINIT_ flags determine the threading model that will be used when a module is loaded by COM. Since the abovementioned flag apparently is not supported, COM must be initialized with the other flag COINIT_MULTITHREADED instead. However, unfortunately many ActiveX controls are written using the Apartment Threading model. Under normal circumstances, when COM tries to load the ActiveX control, the CoGetClassObject API checks the control’s entry in the registry to find its location and characteristics. But in these cases it discovers an incompatible threading model, listed as “Apartment” under the key HKEY_CLASSES_ROOT\CLSID\{}\InprocServer32\ThreadingModel.
Since this contradicts the COINIT_MULTITHREADED flag, CoGetClassObject will fail with an error complaining that the COM class is improperly registered.
The workaround for this error is to change the registration of the ActiveX control such that the InprocServer32\ThreadingModel key is removed from the registry and COM does not discover the mismatch. In an MFC application, this may be done by locating the COleObjectFactory::UpdateRegistry (not UpdateRegistryAll) function in the ActiveX control’s DLL and putting zero in the sixth parameter. Note that this function is usually implemented in an override provided by MFC. (The CoInitialize and CoGetClassObject calls themselves are encapsulated by MFC and do not require direct manipulation.)
|
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
COM problems
Forum Locked
Send Topic to a Friend
Printer Friendly