[python-win32] Win32com events, multithreading, and re-entrancy

[Mark Hammond]

...
> Now, when I run this, I would expect to see a string of dots,
> terminating with "Connected to XXXX". What I actually get is a
> string of dots, then "Connected to", then the string of dots
> resumes indefinitely.
>
> The only explanation that I can see for this is that the access
> to connection.Properties in the event, causes
> PumpWaitingMessages() in the main loop to return, and restart the
> main loop (with "finished" not set). Such flow of control makes
> no sense unless multiple threads are present behind the scenes
> (which could easily be true with ADO/COM), but if they are, I
> have no idea what the call to connection.Properties is waiting
> on, or how to free it up.

Or, it is possible that the access to Properties() is raising an exception.
Try a "finally" clause that prints after the call, or even a full-blown
try/except clause using the traceback module.  The next version of win32all
should print these exceptions to stderr by default.

> Ultimately, my event handler function appears not to be acting as
> an atomic operation, but is somehow interfering with the main
> processing loop.

It is not clear what you expect by "atomic" here.  The call could certainly
trigger any number of "dots" before returning.  I agree infinite dots is not
expected ;)

Ultimately though, what you are trying to do should work, assuming you don't
expect the main thread to do much other than run an event loop as it is now.

*dig dig* - I managed to get a test case working.  There are a couple of
problems, both of which would have shown up with printing the traceback as I
mentioned above.

   def OnConnectComplete(self, error, status, connection):

In this case, connection is a PyIUnknown object - this is strange, and VB
obviously handles this better.  I am fixing win32com so it does too.  For
now, you can use the code:

       connection =
Dispatch(connection.QueryInterface(pythoncom.IID_IDispatch))

And everything will work.

Mark.