COM Event Sinks and Connection Points in Python

[Mark Hammond]

Toby Dickenson wrote in message <3711134d.17632096 at news.freeserve.net>...
>"Mark Hammond" <MHammond at skippinet.com.au> wrote:

>For controls this is to be expected. They are allowed to be fairly
>non-functional until activated, which requires a control site. They might
>implement IDispatch, but they can not be used a 'just' an automation
server.

Actually, in many cases, I can use the functionality of the objects - just
not get events.  Excel, Word and MSAgent are good examples - can use the
IDispatch interfaces fine, but cant get events.

However, Im not convinced it isnt something silly I have done, lacking the
time to give it serious effort.

>If I remove the extra 'return' from testPyComTest.py then I always get a
>Fatal Python error: PyThreadState_Get: no current thread
>Is this the bug you mean? I think I have some answers....

Yes, and great!

>I believe this problem is not caused by a bug in pythoncom, but by several
bugs
>in PyCOMTest, the C++ server that complements this test harness.
>
>In PyCOMImpl.cpp, line 49, a new thread is started. That thread uses the
Fire
>method of the CPyCOMTest object, however this breaks the COM apartment
rules. To
>pass an object reference across apartments you need to use
>CoMarshalInterThreadInterfaceInStream, at least once.

ohh.  Yes.  good point.  This means it probably should work if we init
Pythoncom as free-threaded.

>Secondly, the new thread does not call CoInitializeEx.
Oops.
>
>Hopefully I will have time to dig further next week.

Great - let me know if it fixes it!  However, the particular thread state
error from Python makes me think it wont - the problems you describe would,
to me, imply different symptoms.

I am sort-of hoping that this is actually finding a threading bug in the COM
framework.  If so, it will be useful as it is easily reproducible.  Ahhh,
for more time to play with this stuff...

Mark.