Re: adding event sink functionality to a COM client not set up as a server
Jason S <jmsachs@gmail.com> wrote:
Anything implementing a COM object is, technically, a COM server. But
since you don't need to expose COM-creatable objects, you don't need
a full blown server. E.g. you don't need to register anything.
Interesting. Thanks for the insight. Let me see if I get the
implications of this correctly.
a) IDL file (defines interface) -- one is needed, but I'm doing it
elsewhere, anyway.
For an event sink or callback, the IDL is normally provided by the
server, not by the client. After all, the server knows what kind of
callback it expects. The server also usually provides marshalling
support if necessary.
d) creating a class object -- So this is not necessary? (for the same
reason as (c))
I'm not sure what you mean by class object. If you mean class factory
(an object implementing IClassFactory) - no, you don't need it. You can
just create your object with 'new', or, since you appear to be using
ATL, with CComObject::CreateInstance. You don't need to derive your
class from CComCoClass
e) create the COM object itself that implements the sink interface --
all I have to do is implement QueryInterface/Addref/Release + my
interface methods, then? (And I can implement the IUnknown methods
with the CComObjectRootEx<> template and a
COM_MAP/COM_INTERFACE_ENTRY, yes?)
Correct on all counts.
f) threading/msg loop issues: I'm not quite clear about this. My
client program is a GUI w/ a message loop. What exactly happens when
the event source, in another process, fires an event? The proxy/stub
comes into play; do I need to worry about this disrupting or blocking
my main GUI thread, or will the event call happen asynchronously?
You are now a server - your sink is accepting calls from outside. Your
GUI application's main thread should enter STA (by calling CoInitialize
or similar) - it's probably doing that anyway. It should also run a
message pump - again, it's very likely doing that already. An external
COM call is delivered to you in the form of a window message posted to a
hidden window COM maintains on your behalf. Your regular message pump
will retrieve and dispatch the message, which then goes to COM-provided
window proc which will turn around and call your object's method. As far
as UI is concerned, a method call is not much different from a regular
message handler.
--
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