Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"RuntimeError: Calling Tcl from different appartment"

819 views
Skip to first unread message

Peter Saffrey

unread,
Jun 21, 2004, 10:46:18 AM6/21/04
to
I am writing a multi-threaded Tkinter application. It worked fine with
Python 2.2 under Redhat 8.0, but I have recently moved across to
Debian (testing/unstable) and Python 2.3. Now I get the above error
message.

I read on this group somewhere that this is caused by calling Tk
functions from a different thread to where the interface is running.
Unfortunately, I really need to do this and cannot have all my Tk
calls within one thread. Is there a way around this? Why did it work
in 2.2 but not 2.3?

Thanks,

Peter

Aahz

unread,
Jun 21, 2004, 11:16:06 AM6/21/04
to
In article <ced73313.04062...@posting.google.com>,

Peter Saffrey <theo...@my-deja.com> wrote:
>
>I am writing a multi-threaded Tkinter application. It worked fine with
>Python 2.2 under Redhat 8.0, but I have recently moved across to
>Debian (testing/unstable) and Python 2.3. Now I get the above error
>message.
>
>I read on this group somewhere that this is caused by calling Tk
>functions from a different thread to where the interface is running.

Yup.

>Unfortunately, I really need to do this and cannot have all my Tk
>calls within one thread. Is there a way around this? Why did it work
>in 2.2 but not 2.3?

No clue why it used to work. Why do you need to call Tk from multiple
threads?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"Typing is cheap. Thinking is expensive." --Roy Smith, c.l.py

Peter Saffrey

unread,
Jun 22, 2004, 5:56:16 AM6/22/04
to
aa...@pythoncraft.com (Aahz) wrote in message news:<cb6u3m$9fn$1...@panix1.panix.com>...

> In article <ced73313.04062...@posting.google.com>,
> Peter Saffrey <theo...@my-deja.com> wrote:
>
> No clue why it used to work. Why do you need to call Tk from multiple
> threads?

I'm writing an MP3 jukebox (don't laugh, it's just for fun). One
thread controls the interface that shows the next few songs to be
played and allows you to add to the list. The other thread plays the
songs, removing them from the list in the process. To control this
with one thread, I'd have to have the interface thread constantly
listening for when the last song has finished so that it can remove it
from the list and play the next one.

Peter

Eric Brunel

unread,
Jun 22, 2004, 6:12:06 AM6/22/04
to

No you don't. There's one thing you can do in secondary threads wrt to Tkinter:
posting events in Tkinter event queue via the event_generate method. Here is an
example:

--tkinterNThreads.py-----------------------------------------
import threading, time
from Tkinter import *

root = Tk()

def ping():
while 1:
time.sleep(1)
root.event_generate('<<Ping>>', when='tail')

v = BooleanVar()
v.set(0)
Checkbutton(root, variable=v, text='Ping!').pack(side=TOP)
Button(root, text='Quit', command=root.quit).pack(side=TOP)

def gotPing(event):
v.set(not v.get())

root.bind('<<Ping>>', gotPing)

th = threading.Thread(target=ping)
th.setDaemon(1)
th.start()

root.mainloop()
-------------------------------------------------------------

The secondary thread make the check-button blink by generating custom <<Ping>>
events in Tkinter event queue. Note the option when='tail' in event_generate is
mandatory: if you don't set it, there's a chance that the event is treated
immediatly without switching threads.

The code above works on Linux and Windows (there are other issues on Solaris,
but I assume it won't be your target platform...)

HTH
--
- Eric Brunel <eric (underscore) brunel (at) despammed (dot) com> -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com

0 new messages