On Mon, 17 Jul 2006 15:20:46 +0200, Claus Tondering
<[EMAIL PROTECTED]> wrote:
> Eric Brunel wrote:
>> This is where the problem is: if you do just a event_generate without
>> specifying the 'when' option, the binding is fired immediately in the
>> current thread. To be sure that an event is cre
Eric Brunel wrote:
> This is where the problem is: if you do just a event_generate without
> specifying the 'when' option, the binding is fired immediately in the
> current thread. To be sure that an event is created and that the thread
> switch actually happens, do:
>
> app.event_generate("<>", wh
On Mon, 17 Jul 2006 12:58:08 +0200, Claus Tondering
<[EMAIL PROTECTED]> wrote:
> My Tkinter application has to receive events from a TCP connection. I
> have chosen to do this in the following manner:
>
> The TCP communication takes place in a separate thread. When I receive
> data, I generate a
"Claus Tondering" <[EMAIL PROTECTED]> writes:
> Does this mean that I cannot even call the main thread's after_idle
> method from another thread?
I'm not certain, I've never tried it that way since there's no way I
could be confident of its reliability even if it appeared to work.
Just use after_i
Paul Rubin wrote:
> Tkinter is simply not
> thread safe and generating events from another thread can trigger race
> conditions and who knows.
Does this mean that I cannot even call the main thread's after_idle
method from another thread?
--
Claus Tondering
--
http://mail.python.org/mailman/lis
"Claus Tondering" <[EMAIL PROTECTED]> writes:
> The TCP communication takes place in a separate thread. When I receive
> data, I generate an event in the Python application thus:
>
> app.event_generate("<>")
I think all bets are off when you do that. Tkinter is simply not
thread safe and gen
