Mac OS X IBook G4 PowerPC when running target.py it works fine until i close the app without ending the process. (before 'q' is entered by the user). sometimes python will not allow the user to click in the window and have the ability to type after running the target window. sometimes the mouse clicks affect a part of IDLE up and left of where the actual click was. when i ignore this error (this is the only thing i have open in IDLE) i must fist close out of python and reopen target.py i have used this approach to test and find that there are no bugs in my program (at least it works above and beyond the specifications of my class assignment), but every once in while i will get an error when trying to use 'q' to end the program and python will state that win.getMouse() is not a viable term to use, because (win) is already closed yet when 'q' is used the if statement has the close command right underneath the get mouse command. *note* i have coded another program specifically from John Zelle's "Python Programming: An Introduction to Computer Science" p.160 programming exercise #1 and my get display text, get mouse, then close window is verbatim from that in target.py and it never showed an error in the #1's program IDLE can't bind TCP/IP port 8833, which is necessary to communicate with its Python execution server. Either no networking is installed on this computer or another process (another IDLE?) is using the port. Run IDLE with the -n command line switch to start without a subprocess and refer to Help/IDLE Help 'Running without a subprocess' for further details.
The test program depends on an external third-party module graphics. From the problem description and a web search, I assume the file is: http://mcsp.wartburg.edu/zelle/python/graphics.py Can you confirm that? Using that module, target.py runs on 10.5 invoking python2.6 directly with Apple-supplied Tk 8.4.7 or under idle2.6. However, with a python2.6 using ActiveState Tk 8.4.19 installed on 10.5 or 10.6, target.py fails with: Tk_MacOSXSetupTkNotifier: first [load] of TkAqua has to occur in the main thread! As of 10.6(.2), attempts to run with a Tkinter linked to the Apple- suppled Tk 8.5.7 hang (similar problems noted with other apps). I was not able to reproduce the error message your report but there are certainly known and/or suspected issues with Tkinter and Apple's Tk 8.4.7, even more likely running under IDLE which uses Tkinter itself. I'm not sure what action to recommend with this issue. Perhaps it makes the most sense to leave it open until Tkinter with Apple Tk 8.5 is working reliably and then retest. BTW, the message "IDLE can't bind TCP/IP port 8833" most likely indicates one of the IDLE processes has aborted leaving another waiting for the socket to close. Ideally, that shouldn't happen. Thanks for the problem report.
The "graphics" module runs Tk in a separate thread, which means it accesses the Apple GUI frameworks from a thread that is not the main thread. This is AFAIK not supported by Apple, which would explain why it doesn't work. I'll look for a link to the relevant Apple documentation before closing this.
<http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Mul tithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/u id/10000057i-CH12-SW1> summarizes the thread safety aspects for Apple GUI programs. Basicly all eventhandling needs to be done on the main thread. This means that this issue is not a python bug, but a platform issue that we cannot fix or work around. I therefore propose to close this issue.
History
Date
User
Action
Args
2022-04-11 14:56:54
admin
set
github: 51439
2009-12-08 16:45:28
ronaldoussoren
set
status: pending -> closed
2009-11-11 12:05:57
ronaldoussoren
set
status: open -> pendingtype: crash -> behaviormessages: + resolution: not a bugstage: resolved
2009-11-11 07:20:10
ronaldoussoren
set
messages: +
2009-11-11 03:19:04
ned.deily
set
nosy: + ned.deilymessages: + title: TCP/IP? -> Problems running threaded Tkinter program under OS X IDLE
