Problem with using PythonWin and ActiveX COM Object
aleaxit at yahoo.com
Fri Oct 6 09:26:34 CEST 2000
"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
> > > >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!
More information about the Python-list