"RuntimeError: Calling Tcl from different appartment"

Discussion in 'Python' started by Peter Saffrey, Jun 21, 2004.

  1. 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
     
    Peter Saffrey, Jun 21, 2004
    #1
    1. Advertising

  2. Peter Saffrey

    Aahz Guest

    In article <>,
    Peter Saffrey <> 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 () <*> http://www.pythoncraft.com/

    "Typing is cheap. Thinking is expensive." --Roy Smith, c.l.py
     
    Aahz, Jun 21, 2004
    #2
    1. Advertising

  3. (Aahz) wrote in message news:<cb6u3m$9fn$>...
    > In article <>,
    > Peter Saffrey <> 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
     
    Peter Saffrey, Jun 22, 2004
    #3
  4. Peter Saffrey

    Eric Brunel Guest

    Peter Saffrey wrote:
    > (Aahz) wrote in message news:<cb6u3m$9fn$>...
    >
    >>In article <>,
    >>Peter Saffrey <> 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.


    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
     
    Eric Brunel, Jun 22, 2004
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page