Python COM and DCOM.

[Alex Martelli]

"Syver Enstad" <syver at NOSPAMcyberwatcher.com> wrote in message
news:3RV96.10957$wt2.125028 at news1.oke.nextra.no...
> I am having a bit of a problem getting a python COM object to work over
> DCOM.
>
> As far as I can see I've done exactly what is proposed in the Python on
> Win32 book. But the object is started on the local machine, when using
> win32com.client.Dispatch or the default instance creation methods in other
> languages such as JScript with ASP and C++. It seems like DCOM works when
> using the DispatchEx to explicitly choose the machine to run on but not
> else.
>
> Help very much appreciated, thank you.

If you register a COM object as having different servers (in-process,
local aka out-of-process, remote), the fastest one of these will
always be used by 'default instance creation methods' in all
languages.  You will need to de-register the 'faster' (in-process,
local) servers if you want 'slower' servers to be used for such
default creation.

Or else (not available from all languages) you can explicitly ask
for the kind of server you want by passing appropriate values from
the CLSCTX enumeration:

typedef enum tagCLSCTX
{
    CLSCTX_INPROC_SERVER    = 1,
    CLSCTX_INPROC_HANDLER   = 2,
    CLSCTX_LOCAL_SERVER     = 4,
    CLSCTX_REMOTE_SERVER    = 16,
    CLSCTX_NO_CODE_DOWNLOAD = 400,
    CLSCTX_NO_FAILURE_LOG = 4000
} CLSCTX;
#define CLSCTX_SERVER    (CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER |
CLSCTX_REMOTE_SERVER)
#define CLSCTX_ALL       (CLSCTX_INPROC_HANDLER | CLSCTX_SERVER)

to whatever activation API (CoCreateInstance, CoCreateInstanceEx,
CoGetClassObject, etc.) is being used to activate the object --
not all languages will expose their mechanisms for object
activation allowing such fine-grained control, though.


Alex