....
....
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.
b) proxy/stubs -- these are needed but I'm already using the IDL file
elsewhere to build a proxy/stub DLL anyway.
c) registering CLSID/IID/server/etc. in the registry -- not needed.
(because the event sink objects are only going to be created within my
client program, by my client program's volition. The IID is not
necessary to register if all my clients/servers have access to the same
IDL file (or TLB if runtime) that defines the interface.)
d) creating a class object -- So this is not necessary? (for the same
reason as (c))
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?)
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?
g) lifetime management -- If the event source honors my Unadvise()
method, then I shouldn't have to worry about event sink objects having
to exist outside my client program's existence.
h) anything else? (not that I can think of)
Do you find COM clients that sink regular COM events (connection points
and all that) messy? A connection point is a way for the client to
implement a COM object and pass its pointer to the server, so
technically the client becomes a server itself. This is perfectly
normal.
"Messy" might have been the wrong word. I'm a hardware engineer, not a
software engineer, and this project is only one of several tasks in my
job; it's taking too much time and is getting rather complex. I'm in a
mode where eliminating complexity is an extremely high priority,
whether that complexity is implementation (lots of details) or
architecture (lots of quirky high-level design issues) or conceptual
(just being able to understand how COM works). Connection points fall
into the latter category for me -- I've read the sections on them in
Essential COM and ATL Internals, and my eyes glaze over... whereas I
can understand the idea of a more simple source/sink interface that
doesn't involve interface discovery/enumeration or whatever it is that
connection points do.
Probably at least 60% of the time I've spent on COM-related tasks has
been trying to get my head around the concepts of COM (especially
proper interface design + object lifetime management) and how to use
them correctly in a real project, even a moderately simple real
project. (vs. the ICatDog or IFlyingBird type of examples)