By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,501 Members | 1,678 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,501 IT Pros & Developers. It's quick & easy.

wxPython: non-GUI thread launching new frame? Delegates?

P: n/a
In my wxPython app a non-GUI thread (that reads info from the network)
tries to open a frame to show the new info. This results in my app
hanging (which is not too surprising). Coming from a C# environment I
wonder if there is some sort of delegate mechanism in wxPython to do
this sort of thing.

2B

Feb 20 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
cyberco wrote:
In my wxPython app a non-GUI thread (that reads info from the network)
tries to open a frame to show the new info. This results in my app
hanging (which is not too surprising). Coming from a C# environment I
wonder if there is some sort of delegate mechanism in wxPython to do
this sort of thing.
Not sure how wx deals with this, but one thing you might explore is the
possibility to add a timer in the GUI-thread, that polls a thread-filled
queue.

Other toolkits as Qt have means to insert an extra event in the event queue
of the gui-thread in a thread-agnostic way, maybe wx has that too.

Googling...
....
....
....

.... finished

http://mail.python.org/pipermail/pyt...st/335467.html

"""
You need another way to pass completion information between the downloader
thread and the main thread; the simplest way is to define a custom wx
Event, and wxPostEvent from the downloader thread when it completes (
and when the gauge should be updated). wxPostEvent is safe to call from
non-eventloop threads.
The main thread's wx event loop just spins, properly updating all other
parts of the GUI, and receiving events from the downloader thread.

ANother approach is to have a thread-safe Queue and have the main
thread/event loop
poll the queue with queue.get_nowait() periodically (typically 0.1-1 sec).
The downloader thread shares the queue object and puts data structures
(typically
class instances, strings, or ints) that indicate status updates.
"""

So - both options a viable. And read to the end, the twisted-approach
certainly is the most clean one.

Diez
Feb 20 '07 #2

P: n/a
On 2/20/07, Diez B. Roggisch <de***@nospam.web.dewrote:
cyberco wrote:
In my wxPython app a non-GUI thread (that reads info from the network)
tries to open a frame to show the new info. This results in my app
hanging (which is not too surprising). Coming from a C# environment I
wonder if there is some sort of delegate mechanism in wxPython to do
this sort of thing.

Not sure how wx deals with this, but one thing you might explore is the
possibility to add a timer in the GUI-thread, that polls a thread-filled
queue.

Other toolkits as Qt have means to insert an extra event in the event queue
of the gui-thread in a thread-agnostic way, maybe wx has that too.

Googling...
...
...
...

... finished

http://mail.python.org/pipermail/pyt...st/335467.html

"""
You need another way to pass completion information between the downloader
thread and the main thread; the simplest way is to define a custom wx
Event, and wxPostEvent from the downloader thread when it completes (
and when the gauge should be updated). wxPostEvent is safe to call from
non-eventloop threads.
The main thread's wx event loop just spins, properly updating all other
parts of the GUI, and receiving events from the downloader thread.

ANother approach is to have a thread-safe Queue and have the main
thread/event loop
poll the queue with queue.get_nowait() periodically (typically 0.1-1 sec).
The downloader thread shares the queue object and puts data structures
(typically
class instances, strings, or ints) that indicate status updates.
"""

So - both options a viable. And read to the end, the twisted-approach
certainly is the most clean one.
This is rather out of date. wxPython provides a wx.CallAfter function,
which will call the passed callable on the next spin through the event
loop. It's essentially a wrapper around the custom event mechanism
described above.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
Feb 20 '07 #3

P: n/a
Ah! Great tip, thanks!
Now instead of calling:

parent.onRequest(param)

I call:

wx.CallAfter(lambda x: parent.onRequest(x), param)

Way cool.
2B
This is rather out of date. wxPython provides a wx.CallAfter function,
which will call the passed callable on the next spin through the event
loop. It's essentially a wrapper around the custom event mechanism
described above.
Diez
Feb 20 '07 #4

P: n/a
On 2007-02-20, cyberco <cy*****@gmail.comwrote:
Ah! Great tip, thanks!
Now instead of calling:

parent.onRequest(param)

I call:

wx.CallAfter(lambda x: parent.onRequest(x), param)
How does that differ from this?

wx.CallAfter(parent.onRequest, param)

--
Grant Edwards grante Yow! .. Everything
at is....FLIPPING AROUND!!
visi.com
Feb 20 '07 #5

P: n/a
On 20 Feb 2007 12:01:02 -0800, cyberco <cy*****@gmail.comwrote:
Ah! Great tip, thanks!
Now instead of calling:

parent.onRequest(param)

I call:

wx.CallAfter(lambda x: parent.onRequest(x), param)
You don't need the lambda - you can use:

wx.CallAfter(parent.OnRequest, param)
Feb 20 '07 #6

P: n/a
Oh boy....I must have hit an all time programmers-low with this....
That was plain stupid.
2B
You don't need the lambda - you can use:

wx.CallAfter(parent.OnRequest, param)

Feb 21 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.