"RuntimeError: Calling Tcl from different appartment"

P

Peter Saffrey

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
 
A

Aahz

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?
 
P

Peter Saffrey

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
 
E

Eric Brunel

Peter said:
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.

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top