Hey,
I’ve always been under the impression that if I send an event via EvtHandler.ProcessEvent (from a subclassed object) any handlers bound to the object would get run on the main thread. Is that correct? I guess I can change them to do ProcessEvent in a CallAfter if not - just wanted confirmation :).
Cheers!
Paul
Paul Wiseman wrote:
I've always been under the impression that if I send an event via
EvtHandler.ProcessEvent (from a subclassed object) any handlers bound
to the object would get run on the main thread. Is that correct? I
guess I can change them to do ProcessEvent in a CallAfter if not -
just wanted confirmation :).
No, ProcessEvent will run in the current thread. It calls the event
handlers directly with no indirection. There is no thread switch.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Ahhhh Thanks Tim!!
Was a misconception I had! What’s the best want to get it onto the main thread? Just to do it in a call after? Usually I’ll have UI updates in the event handlers so I want to get them onto the main thread.
On 25 November 2013 19:04, Tim Roberts timr@probo.com wrote:
Paul Wiseman wrote:
I’ve always been under the impression that if I send an event via
EvtHandler.ProcessEvent (from a subclassed object) any handlers bound
to the object would get run on the main thread. Is that correct? I
guess I can change them to do ProcessEvent in a CallAfter if not -
just wanted confirmation :).
No, ProcessEvent will run in the current thread. It calls the event
handlers directly with no indirection. There is no thread switch.
–
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Paul Wiseman wrote:
Ahhhh Thanks Tim!!
Was a misconception I had! What's the best want to get it onto the
main thread? Just to do it in a call after? Usually I'll have UI
updates in the event handlers so I want to get them onto the main thread.
Yep, CallAfter is usually the easiest way to do that.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Perfect ta!
and viola - all the random crashes have gone 
On 26 November 2013 18:01, Tim Roberts timr@probo.com wrote:
Paul Wiseman wrote:
Ahhhh Thanks Tim!!
Was a misconception I had! What’s the best want to get it onto the
main thread? Just to do it in a call after? Usually I’ll have UI
updates in the event handlers so I want to get them onto the main thread.
Yep, CallAfter is usually the easiest way to do that.
–
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Hi Tim
I’ve had several system wide crashes with using the ProcessEvents from another thread. This means Windows explorer locks up requiring a reboot.
Details: Win7 64b, wxpython 2.8.12.1, python wrapped as EXE by py2exe.
Does it make sense this is the cause? i.e. Could calling ProcessEvents from another thread cause windows to Crash?
If I need to call the event handler immediately, I don’t want to have the event processed later, what is the easiest way?
On Tuesday, November 26, 2013 at 8:01:07 PM UTC+2, Tim Roberts wrote:
Paul Wiseman wrote:
Ahhhh Thanks Tim!!
Was a misconception I had! What’s the best want to get it onto the
main thread? Just to do it in a call after? Usually I’ll have UI
updates in the event handlers so I want to get them onto the main thread.
Yep, CallAfter is usually the easiest way to do that.
–
Tim Roberts, ti...@probo.comProvidenza & Boekelheide, Inc.
Uri Shabi wrote:
I've had several system wide crashes with using the ProcessEvents from
another thread. This means Windows explorer locks up requiring a reboot.
Is your application running as an Explorer shell add-on? If not, then
there's no way it should be affecting Explorer.
1. Does it make sense this is the cause? i.e. Could calling
ProcessEvents from another thread cause windows to Crash?
No.
2. If I need to call the event handler immediately, I don't want to
have the event processed later, what is the easiest way?
There is no other way. That's just not how event-driven systems work.
You cannot FORCE a thread to stop what it's doing and handle your request.
However, the delay is not usually significant, especially if your
request comes in from another thread. What CallAfter does is put a
windows message in the main thread's message queue. Unless the main
thread is busy, that will trigger an event that wakes the main thread up
and makes it available to run as soon as a CPU is available. If the
main thread is busy, then you must wait for it to get back to its
message loop to check for another message.
I suspect you are simply thinking about your problem in the wrong way.
You said you are talking about UI updates, right? UI updates do not
need immediacy. Remember that it's going to take another screen refresh
(at least 16ms) before any change you make is even visible to the user.
In processor terms, UI updates are lazy.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.