Robalitoru
asked on
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OK, thanks, interesting solutions, I'll look into them and let you know.
Bye!
Bye!
ASKER
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!
Thanks!
- 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"