python com wrappers

P

Paul Rudin

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?
 
P

Paul Rudin

Paul" == Paul Rudin said:
> 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?
 
J

John J. Lee

Paul Rudin said:
seems to solve the problem, although perhaps this breaks something
else?

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


John
 
R

R.Marquez

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top