All Forums
 Microsoft Windows CE
 eVC Application Development
 COM problems
 Forum Locked
 Send Topic to a Friend
 Printer Friendly
Author Topic  

rowe2

4 Posts

Posted - 04 Oct 2002 :  09:00:43  Show Profile  Email Poster
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  Show Profile  Email Poster
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.
Go to Top of Page

rowe2

4 Posts

Posted - 07 Oct 2002 :  10:49:58  Show Profile  Email Poster
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
Go to Top of Page

ctacke

877 Posts

Posted - 07 Oct 2002 :  11:52:39  Show Profile  Email Poster
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?
Go to Top of Page

vtk100

40 Posts

Posted - 24 Jul 2003 :  12:00:49  Show Profile  Email Poster
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?
Go to Top of Page

mburr

3 Posts

Posted - 07 Aug 2003 :  11:18:19  Show Profile  Email Poster
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.)
Go to Top of Page
  Topic  
 Forum Locked
 Send Topic to a Friend
 Printer Friendly
Jump To:
Eurotech Support Forums © Eurotech Inc. Go To Top Of Page
This page was generated in 0.03 seconds. Snitz Forums 2000