"Eric Brunel" <[EMAIL PROTECTED]> wrote
>You don't need to in fact: from the secondary thread, it seems to be safe
>to post a user-defined event in the GUI event loop on which you can set a
>binding in the GUI thread. This allows a thread switch without having to
>do a periodical check.
>
8
On Fri, 28 Nov 2008 04:20:22 +0100, Hendrik van Rooyen
<[EMAIL PROTECTED]> wrote:
If you are not already doing it, you need to make a "stutter thread"
by using the after() call on some gui object to periodically check for
input on the queue.
You don't need to in fact: from the secondary thread
<[EMAIL PROTECTED]> wrote:
On 26 Nov, 13:42, Steve Holden <[EMAIL PROTECTED]> wrote:
>> One approach would be to run the socket code in blocking mode in a
>> separate thread started by the (main program) GUI thread at program
>> startup, and communicating results back via a Queue.Queue or simil
On 26 Nov, 13:42, Steve Holden <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hi all, I'm new to python and I've been spending the last week on GUI
> > that refresh its content based on data periodically coming from a
> > remote socket.
> > I succeded in doing it (thanks newsgroups and o
[EMAIL PROTECTED] wrote:
> Hi all, I'm new to python and I've been spending the last week on GUI
> that refresh its content based on data periodically coming from a
> remote socket.
> I succeded in doing it (thanks newsgroups and online manual!) using
> the Tkinter.after method to implement a busy
Hi all, I'm new to python and I've been spending the last week on GUI
that refresh its content based on data periodically coming from a
remote socket.
I succeded in doing it (thanks newsgroups and online manual!) using
the Tkinter.after method to implement a busy wait on the socket (which
I had pre
