Inhibiting COM object creation

  I have a COM server, NT service, created with ATL which contains two COM classes each exposing an interface. The interfaces are very much the same, serving similar functionality, but the underlying implementation differs greatly. From reasons beyond the scope of this question (in short terms, is because each implementation has it's advantages) I want to keep both COM objects available for the client.
   When the service is starting I read some parameters from a configuration file. Based on this I have to initialize lots of static data, which will be used to serve requests on one of the interfaces.
   It will all work fine as long as the clients will ask for objects of the COM class matching the current configuration, and the server is stable enough to deal even with the requests on the "wrong" interface - that is, the one not conform with the configuration, so this is not a "help me, I'm desperate" question.

   What I want to do though, is go beyond testing the availability of the necessary static data upon requests on the interfaces, and inhibit the object creation for the COM class objects that do not conform to the current configuration.
   My guess is that I would have to overwrite the class factory functionality - this would be much more handy if I would have written the whole thing from scratch - but this way I have to deal with the ATL in a way, I think, less then pleasant.

   My question is:
   Is it possible to inhibit the object creation? ( If no, I would like a detailed explanation in order to award the points. )
   If yes - I will need pointers for where to hack in the code.
   
LVL 1
RobalitoruAsked:
Who is Participating?
 
GGRUNDYConnect With a Mentor Commented:
This is what I would try....

Only declare one class in the standard Object map,
and create a second object map contaninging the 2nd class
in another objected map. In your initialisation code
if you determine that you should be serving the 2nd class
just overwrite the 1st entry with the 2nd.

e.g. Instead of
BEGIN_OBJECT_MAP(ObjectMap)
OBJECT_ENTRY(CLSID_Obj1, Obj1)
OBJECT_ENTRY(CLSID_Obj2, Obj2)
END_OBJECT_MAP()


declare it this way...
BEGIN_OBJECT_MAP(ObjectMap)
OBJECT_ENTRY(CLSID_Obj1, Obj1)
END_OBJECT_MAP()

BEGIN_OBJECT_MAP(AlternateObjectMap)
OBJECT_ENTRY(CLSID_Obj2, Obj2)
END_OBJECT_MAP()


then in your initialisation code do this

if(isAlternateConfigActive){
  ObjectMap[0] = AlternateObjectMap[0];
  }


Cheers
0
 
jkrCommented:
You could actually do two things:

- return "FALSE" from within the "QueryInterface()" method of the class that shouldn'be created.

or

- "redirect" the "unwanted" interface to a class that handles that by calling "CoTreatAsClass()" from your code, specifying that "handler object"
0
 
RobalitoruAuthor Commented:
  OK, thanks, interesting solutions, I'll look into them and let you know.
   Bye!
0
 
RobalitoruAuthor Commented:
  So, I looked into them, and implemented GGRUNDY's solution. It was the most appropiate for what I needed, and quite easy to implement.
  Thanks!
   
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.