How call running process?

[Alex Martelli]

"Dag W" <dag at whoi.edu> wrote in message news:39BFC414.2E373678 at whoi.edu...
> A question about pythonwin/win32com
>
> How do you from one COM object (A) find and get at another, already
> running COM server (B)? The most examples I have come across create a
> new COM server, do their stuff and everything is fine.
>
> If object B already is running and I want to inspect its state from A,
> how do I find B, and get access to its methods? I have done some of the

If B wants to be 'findable', it sets some moniker to itself in a
place where A can locate it and use it to bind it to B.  The
simplest case, for example, is RegisterActiveObject, where
B can register itself in the 'Running Object Table' (ROT) as
"the" currently active object of its coclass (there can be more
than one, but it's mostly intended for process-unique in-process
servers or system-unique local servers; when A calls
GetActiveObject, it will retrieve at most one binding...).  Here,
the CLSID works as the 'moniker', in practice.

The general use of monikers is rich and complex.  But one
easy (if simplistic...) possibility is to use FileMonikers -- even
for objects that don't really persist/depersist to files... OK,
that is bending the rules a bit, but it does work as a way to
"just tag this currently running object with a tag that can be
passed around", since FileMonikers that are currently bound
also implicitly register themselves in the ROT.  If your object
implements IPersistFile, and is started that way (with a Load),
this could also be used to locate it.

"The Book" on this subject is Don Box's "Essential COM".  All
the explanation is in C++, but, it's really mostly very simple
C++.  And I've never found a clearer explanation of some of
the most fundamental use of Monikers...

There are other approaches, that depend on using other
global objects rather than the ROT (so you can establish
your own rules... rather than necessarily following the
moniker protocols).  E.g., have a system-unique object
DogLocator (RegisterActiveObject it, so that everybody
can find it...) that knows about every Dog that is active
in the system (because Dog objects know to tell it about
themselves...) and can be queried for them.  Setting up
the 'weak references' the locator needs to have to the
objects it locates is trickier (though you can play tricks
with synthetic GUIDs in the ROT itself...) -- that's part
of what the moniker protocol handles for you in exchange
for its complexity...


Alex