Debugging tkinter applications
-
retag
add tags
I'm using Wing Pro 9.1.2.0.
When my tkinter application raises an exception, the debug information shows up in the Debug I/O tab, but not the Exceptions tab.
For example:
File "/usr/lib/python3.11/tkinter/__init__.py", line 1702, in configure return self._configure('configure', cnf, kw) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/tkinter/__init__.py", line 1692, in _configure self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) _tkinter.TclError: unknown color name
Is there a way to have the exception above show in the Exceptions tab, so that I can click on it and have it take me to the line with the issue? The Debug I/O tab is shown in plain text, so clicking on the exception won't take me to the line in the editor.
I tried adding TclError to the Exceptions configuration, under 'Always Report', but that didn't make a difference for me. Any ideas? Thanks.
Comments
Do you have the Debugger > Exceptions preference in Wing set to When Printed (Default) or some other value? It's possible Tkinter is printing this in some odd way, and setting a breakpoint on the line where it occurs may allow you to look up the stack and see what it's doing.
Debugger -> Exceptions is set to When Printed (Default) . I think I found out what the issue is: I'm using a module called Pygubu (which is used for creating a tkinter GUI using a design editor and loading the .ui file into the project) - something similar to Qt Designer but for tkinter, and that's why it's showing exceptions in the Debug I/O area instead of the Exceptions tab. If I use plain tkinter without Pygubu, the exceptions show up in the Exceptions area.
Thanks for the advice!
1 Answer
Sort by oldest newest most voted
Interesting, so Pygubu may be doing something odd with the exception hook and thus preventing our debugger from seeing the exception, but I'm not sure. That is a general issue seen in various frameworks and it may be possible to turn off its extra debugging support so Wing's debugger can take over. I didn't find anything when I tried to search for a solution to this, but you may be able to figure it out if you stop on a break point where an exception is happening and go up the stack to see if there's any code that conditionalizes whatever Pygubu is doing to handle the exception.
Comments
Your Answer
Add Answer