[python-win32] Re: Can we add 'native COM support' to a 3rd p arty DLL/OLB

[Thomas Heller]

Andrew MacIntyre <Andrew.MacIntyre at aba.gov.au> writes:

> > From: Thomas Heller
> > Sent: Friday, 23 May 2003 6:45 PM
> 
> {...}
> 
> > I have not really followed the discussion, but ctypes has support
> > for vtable based interfaces. I'm currently writing some docs, you may
> > want to check it out:
> > 
> > http://starship.python.net/crew/theller/ctypes/
> > http://starship.python.net/crew/theller/ctypes/com.html
> > http://starship.python.net/crew/theller/ctypes/sum_sample.html
> 
> Well, this looks like it might be able to do what I want.
> 
> I've generated the module interface files with readtlb.py.  One of the 
> libraries tripped readtlb.py by having references to VT_CARRAY (28) & 
> VT_SAFEARRAY (27) which aren't (yet) supported in the TYPES dict.  I 
> fudged TYPES dict entries and it looks like the references to these 
> types are in parts of the object model I don't plan to go near, so I 
> think that's no problem.
> 
> ArcGIS has a very extensive object hierarchy, and consequently most 
> definitions are in a core object library, with the control libraries 
> referring to interfaces & coclasses in the core object library. 
> Consequently, I believe I have to manually modify the generated module 
> interface files to import the right definitions in the right places.
> 
> Each generated interface file has a small number of definitions 
> (classes COMObject, enum, dispinterface & DISPMETHOD + module variables 
> OLECMDID & OLECMDEXCEPT).  With the need to import multiple modules, 
> should these definitions be moved out of the interface files into 
> a separately imported module?

On friday I cleaned up the generated output of readtlb.py quite a bit: I
removed the OLECMDID and OLECMDEXCEPT hack which was only there because
it didn't parse unions, class enum and class COMObject are also removed
(enums now are a direct subclass of c_int, and readtlb generated
coclasses don't have a base class any more), and the dispinterface and
DISPMETHOD stuff went into ctypes.com.automation. If you want you can
update from CVS, although there were other changes as well - non-working
support for inproc servers which I hope to finish this or next week.

> 
> While it would be nice to be able to use Pythonwin & ctypes together, 
> as far as I can make out there's no way to get a useful IUnknown 
> pointer (to feed to ctypes) from Pythonwin's PyIUnknown objects.

I'll try to look into this. Mark, can you give a hint?

> Just how to use ctypes for a control within another window, as distinct 
> from the IE.Application example, eludes me at the moment...

Henk Punt's venster project has a 'ctypes window' which embeds the
internet explorer as activex control, but I fear this is not what you
mean;-)

As soon as the inproc server stuff works, I'll add some axamples for
primitive activex controls implemented in ctypes.

Thomas