Problem with using PythonWin and ActiveX COM Object

[Alex Martelli]

"Mark Hammond" <MarkH at ActiveState.com> wrote in message
news:dZcD5.6900$aD2.18623 at news-server.bigpond.net.au...
> "Alex Martelli" <aleaxit at yahoo.com> wrote in message
> news:8ri8ba02lfe at news1.newsguy.com...
>
> > > >sure the genpy-supplied wrappers are used rather than purely
> dynamic
> > > >dispatching (it's a rather advisable thing anyway, in general),
> but I
> > > >think you might be able to get away without that.
> > >
> > > I haven't tried then genpy interface. That might work.
> >
> > Yes, I may be wrong about the "sometimes being able to get away
> > without that" (or maybe it's for [in,out] parameters only, an even
> > rarer case).
>
> It actually depends on the object.  Some objects provide no type
> information at all, some provide info only in a type library, and some
> objects provide info in a type library and at runtime.

Aha - yes.  Specifically, the IDispatch interface has a GetTypeInfo
method which the object MAY use to supply a pointer to ITypeInfo
interface... but the object doesn't *have* to.  For example, COM
objects implemented in Python don't supply type-info (right?).


> In many cases, this depends on the tool used to create the object.
> Later tools have provided better functionality "for free".  Eg, it
> should come as no surprise that VB implemented objects go the hack!

The normal way to implement a dual-interface (one which does
IDispatch but also exposes the same functionality directly for
compiled languages) is via system-provided API's that use a
ITypeInfo to implement the dispatch part, so it's normal to
be able to provide that type-info directly as well (for the
caller's benefit).  ATL, the current preferred Microsoft framework
for COM server implementation in C++, uses that scheme.

However, an object's implementer doesn't _have_ to go that
route (and, see above, I believe Python itself is an example
of why one might not want to -- particularly when implementing
pure-dispatch rather than dual-interfaces, the type-info may
be seen as implementation-overhead rather than a helper).


> In terms of getting complete type support for Python, by generating
> makepy support you catch the last 2 classes of object.  By not using
> makepy, you only catch the last class of object.
>
> I know that is as clear-as-mud - hence the general rule-of-thumb I use
> is "makepy gets you type info" :-)

I think it's pretty clear (if one has some understanding of what
goes on in COM and Automation behind the scenes), so, thanks for
providing this hint!


Alex