[python-win32] Is it possible to pump messages in thread?

[Richard Bell]

Thanks, that clears things up a bit (I'm new to com and my understanding is
rather tenuous) and I think I understand why this does not work.  The net of
what I think you are saying is that as a practical matter message running
the message pump in a thread has little effect since the messages proper
(and events) will be delivered to the main thread.  Would that it were
otherwise.

Unfortunately, as a general rule for my purposes it is not practicable to
have the main thread spin the message loop.  The underlying reason is that
the application generally has no pre-knowledge of the nature of the web
pages and the pages script.  Absent such knowledge, the application does not
know if the message loop needs to be spun from time to time.

I'm a bit unclear on this comment:

|The reason is that IE itself is not fully
|free-threaded, so events etc will be delivered to the IE "main thread", not
|to the thread it is being currently used from

Isn't IE running in a separate process?  If that is true aren't IE's events
delivered back to my application via COM so that my threading model would be
largely independent from whatever IE is doing (contingent on whatever
python-com does)?  On the assumption that this might be true, I modified my
application per the example in appendix D by:

--- begin python code ---
import sys
sys.coinit_flags=0          # specify free threading
import pythoncom
--- end python code ---

A bit of experimentation suggests that it is not now necessary to run the
message pump at all.  Interestingly, when I modify the event debug print I
find that events are being processed on one of two threads neither of which
is my main thread.  I'm a bit unclear as to why this is so but it is.  I
assume that somewhere within pythoncom messages are being pumped.

>From the point of view of my test application, all appears well but since I
don't really understand what is happening (within pythoncom I guess) or what
your remark concerning IE free-thread really means I'm a bit concerned.  Can
you provide any insight concerning pythoncom's role in this matter
particularly relative to DispatchWithEvents and messages in a free-thread
apartment?

By way of thanks for your help I'll gladly contribute my test application to
the test suite.  I evolved it off of TestExplorer.py which works but is
somewhat misleading concerning event handling (OnVisible is one of the very
few events that can be caught in the fashion used by the current test).
Perhaps others would find some benefit as I now have modified tests for both
an active PumpWaitingMessages off of an event and a free-thread version
(appears to work but I clearly do not really understand why). 

Regards


|-----Original Message-----
|From: Mark Hammond [mailto:mhammond at skippinet.com.au]
|Sent: Tuesday, February 07, 2006 2:30 PM
|To: Richard Bell; python-win32 at python.org
|Subject: RE: [python-win32] Is it possible to pump messages in thread?
|
|>
|> I've a question about this code since it was necessary to create a second
|> event for the ie object even though the original object and it's event
|> should (I believe) be available.  Am I doing something wrong here?
|
|By setting ie.event, you are adding a new attibute to the IDispatch wrapper
|provided by Python.  When you marshall it to another thread, you get a new
|IDispatch object, as the marshal process provided a new pointer.  There is
|no magic that associates multiple instances like that.
|
|Try just passing the event as a normal param.
|
|> Second when I test this code I see that the thread runs ( trace messages
|> thread: tic occur).  But events are not being pumped since none
|> of the event
|> messages occur.  Eventually the thread times out.
|
|By running a message pump in the thread (*and* the main thread), I expect
|to
|see all events always be delivered to the *main* thread, regardless of what
|thread you use it from.  The reason is that IE itself is not fully
|free-threaded, so events etc will be delivered to the IE "main thread", not
|to the thread it is being currently used from - that is the point of the
|marshalling calls you made - to give COM the chance to marshall back to the
|correct thread.
|
|Mark