Re: CoClass - when is it necessary?
Goran <goran.pusic@gmail.com> wrote:
On May 5, 3:19 pm, "Igor R." <igor.rubi...@gmail.com> wrote:
In my project (inproc server dll, VC9/ATL) I've got a lot of COM-
objects, which may not be created externally by the client - these
objects are created within the server and their interfaces are given
to the client when needed.
I can enforce this restriction in 2 ways:
1) Do not define CoClass in the typelibrary and don't implement
anything related to the CoClass with ATL.
2) Mark CoClass as noncreatable, use
OBJECT_ENTRY_NON_CREATEABLE_EX_AUTO macro in the implementation.
I'd like to understand what could be the consequences of the 1st way.
Would my object have some other limitations, besides the fact that it
won't be "seen" from the outer world? What are the benefits of the 2-
nd way, i.e. defining and registering "fully-functional" CoClass, but
blocking its creation?
Thanks.
WRT second approach - I think you need coclass in the type library to
define [default, source] for event sources, for IDEs that use this
info to add event listeners to a COM object.
Other than that, you may want to have a coclass to get a good clsid
for CComCoClass::Error. But you may just as well use GUID_NULL or some
other coclass and go with that. This may be considered poor form,
though. Your client will get no Source in IErrorInfo, which may be
good since you don't really have a coclass, hence no Source
(typically, it's a ProgID) anyhow.
Another (slight, little known and rarely used) benefit of
OBJECT_ENTRY_NON_CREATEABLE_EX_AUTO is that it runs per-class
initialization and clean-up in your override of ObjectMain, should you
provide one.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925