By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,995 Members | 1,253 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,995 IT Pros & Developers. It's quick & easy.

python com wrappers

P: n/a

I'm having a problem with the python wrappers generated from a type
library.

The symptom is that I get failures to find connections points inside
the wrappers when called from DispatchWithEvents or WithEvents -
e.g. "com_error: (-2147220992, 'CONNECT_E_NOCONNECTION', None, None)"

It seems that the coclass_clsid property of some classes is
incorrect. It seems that when a coclass in the type library has
multiple "[source] dispinterface" it can happen that this coclass can
end up as the one referenced by each of the corresponding
DispatchBaseClass subclasses via the coclass_clsid property, whereas
probably what should happen is that only ones that are default should
be so treated.

But maybe I'm misdiagnosing the problem; has anyone else seen this
and/or know what the problem is?

Jul 18 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
>>>>> "Paul" == Paul Rudin <pa********@scientia.com> writes:
I'm having a problem with the python wrappers generated from a
type library. The symptom is that I get failures to find connections points
inside the wrappers when called from DispatchWithEvents or
WithEvents - e.g. "com_error: (-2147220992,
'CONNECT_E_NOCONNECTION', None, None)" It seems that the coclass_clsid property of some classes is
incorrect. It seems that when a coclass in the type library has
multiple "[source] dispinterface" it can happen that this
coclass can end up as the one referenced by each of the
corresponding DispatchBaseClass subclasses via the coclass_clsid
property, whereas probably what should happen is that only ones
that are default should be so treated. But maybe I'm misdiagnosing the problem; has anyone else seen
this and/or know what the problem is?


To test this I had a quick look at the code that generates the
wrappers. In win32com/client/genpy.py The class Generator has a method
_Build_CoClassChildren. Replacing the line:

dispItem.coclass_clsid = coclass.clsid

with the lines:

if flags & pythoncom.IMPLTYPEFLAG_FDEFAULT:
dispItem.coclass_clsid = coclass.clsid
seems to solve the problem, although perhaps this breaks something
else?

Jul 18 '05 #2

P: n/a
Paul Rudin <pa********@scientia.com> writes:
[...]
seems to solve the problem, although perhaps this breaks something
else?


Try posting what you just wrote to the python-win32 list.
John
Jul 18 '05 #3

P: n/a
jj*@pobox.com (John J. Lee) wrote in message news:<87************@pobox.com>...
Paul Rudin <pa********@scientia.com> writes:
[...]
seems to solve the problem, although perhaps this breaks something
else?


Try posting what you just wrote to the python-win32 list.
John


John,

Could you provide a pointer to that list? I know of the Mailing Lists
at Source Forge, but they are just a bug reporting one and checkins
one. Thanks.
Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.