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

[cyberco]

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

[Diez B. Roggisch]

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

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/python-list/2005-August/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_nowai t() 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

[Chris Mellon]

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

On 2/20/07, Diez B. Roggisch <deets@nospam.w eb.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/python-list/2005-August/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_nowai t() 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

>

[cyberco]

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

Ah! Great tip, thanks!
Now instead of calling:

parent.onReques t(param)

I call:

wx.CallAfter(la mbda x: parent.onReques t(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

[Grant Edwards]

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

On 2007-02-20, cyberco <cyberco@gmail. comwrote:

Ah! Great tip, thanks!
Now instead of calling:
>
parent.onReques t(param)
>
I call:
>
wx.CallAfter(la mbda x: parent.onReques t(x), param)

How does that differ from this?

wx.CallAfter(pa rent.onRequest, param)

--
Grant Edwards grante Yow! .. Everything
at is....FLIPPING AROUND!!
visi.com

[Chris Mellon]

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

On 20 Feb 2007 12:01:02 -0800, cyberco <cyberco@gmail. comwrote:

Ah! Great tip, thanks!
Now instead of calling:
>
parent.onReques t(param)
>
I call:
>
wx.CallAfter(la mbda x: parent.onReques t(x), param)
>

You don't need the lambda - you can use:

wx.CallAfter(pa rent.OnRequest, param)

[cyberco]

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

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(pa rent.OnRequest, param)