I'm currently reinventing the wheel ;-), implementing 'clones' for the
win32com.client .Dispatch and DispatchWithEve nts functions using ctypes.
It works fairly well, although the more complicated data types like
SAFEARRAY or RECORD are not yet implemented.
The win32com.client versions of these functions require makepy support
(for DispatchWithEve nts), and create this on demand. The ctypes
versions don't require something similar, they are using the ITypeComp
interface at runtime to bind methods, properties, and constants on
demand, for events support they use either IProvideClassIn fo2 to find
the outgoing interface, or iterate through the type library to find the
type info and finally ITypeComp for the default outgoing interface.
For my own sake, I'm trying to keep the ctypes version as compatible as
possible to the win32com versions, although I'm not happy by some of the
design decisions Mark Hammond or whoever wrote this stuff made.
First, constants defined in the type libraries are exposed in the
win32com.client .constants instance, which is internally a sequence of
dictionaries. Wouldn't it be better to have the constants available in
the object returned by the Dispatch() call itself, maybe in a _constants
property? I'm also wondering how VB does this...
My second 'complaint' is about the event handlers. It seems win32com
prepends 'On' to the method handler names if the method itself, as
defined in the type library, doesn't already start with 'On'. Take
Internetexplore r as an example. The DWebBrowserEven ts2 outgoing
interface has methods named "BeforeNavigate 2", "NavigateComple te2", and
"OnQuit". The handlers in Python then must be named
"OnBeforeNaviga te2", "OnNavigateComp lete2", and "OnQuit". The method
names look nice in the Python class implementation, and their templates
are also available as commented out code in the makepy generated files,
but looking at the Internet Explorer type library with Oleview, I find
this very confusing. What is the reason that it was chosen this way?
Thomas
win32com.client .Dispatch and DispatchWithEve nts functions using ctypes.
It works fairly well, although the more complicated data types like
SAFEARRAY or RECORD are not yet implemented.
The win32com.client versions of these functions require makepy support
(for DispatchWithEve nts), and create this on demand. The ctypes
versions don't require something similar, they are using the ITypeComp
interface at runtime to bind methods, properties, and constants on
demand, for events support they use either IProvideClassIn fo2 to find
the outgoing interface, or iterate through the type library to find the
type info and finally ITypeComp for the default outgoing interface.
For my own sake, I'm trying to keep the ctypes version as compatible as
possible to the win32com versions, although I'm not happy by some of the
design decisions Mark Hammond or whoever wrote this stuff made.
First, constants defined in the type libraries are exposed in the
win32com.client .constants instance, which is internally a sequence of
dictionaries. Wouldn't it be better to have the constants available in
the object returned by the Dispatch() call itself, maybe in a _constants
property? I'm also wondering how VB does this...
My second 'complaint' is about the event handlers. It seems win32com
prepends 'On' to the method handler names if the method itself, as
defined in the type library, doesn't already start with 'On'. Take
Internetexplore r as an example. The DWebBrowserEven ts2 outgoing
interface has methods named "BeforeNavigate 2", "NavigateComple te2", and
"OnQuit". The handlers in Python then must be named
"OnBeforeNaviga te2", "OnNavigateComp lete2", and "OnQuit". The method
names look nice in the Python class implementation, and their templates
are also available as commented out code in the makepy generated files,
but looking at the Internet Explorer type library with Oleview, I find
this very confusing. What is the reason that it was chosen this way?
Thomas