On 4/05/2011 12:39 AM, Michael Illgner wrote:
2011/5/3 Mark Hammond<mhamm...@skippinet.com.au>:
There is nothing magic about events - you need to provide your own magic :)
All the calls are still normal blocking calls - so if you want a model
where methods on your com object are done in the background and fire when
complete, you need to fully arrange for however that happens (be it threads
or other non-blocking features.) A win32 message queue is often used, which
is why it is a common requirement that apps using such objects must ensure a
message loop is running on the main thread.
Hmm
My application does not use any win32 functions aside of COM, so a simple
time.sleep(1)
pythoncom.PumpWaitingMessages()
loop started in a thread is sufficient ?
Generally in the main thread, yes. And I basically mis-spoke in my
previous reply - the message queue is often used due to COM using
messaging to marshal between threads rather than the COM objects using
it directly.
It all depends on the object emitting the events - if the COM object
delivers the events synchronously, you would get them delivered as they
are generated - in effect, the COM object is just calling a "normal"
blocking function - it just happens to be your event handler. They are
just normal callbacks all on one thread.
But some objects have a model where you call a method to start some
process and the method returns immediately. In that case the object
will make its own arrangements about how to manage the outstanding
"work" after the start method returns. If it uses a different thread,
it will need to "marshal" the event handlers to that other thread -
then, when it tries to call the event handler, the COM marshaller will
use the message queue so the callback actually happens on the main
thread even though they were emitted from the worker thread - hence the
main thread needs the message pump.
If everything is happening in a free-threaded context though, no message
loop is generally required.
DispatchWithEvents takes or creates a COM object, then instantiates a single
instance of the event class and hooks it up with the object - so there is a
1:1 relationship.
OK
so the eventhandler should be implemented as a kind of singleton ?
If you want every object to wind up calling the same "handler", then
yeah, you would have your event handler delegate to some other singleton.
Cheers,
Mark
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
