Tkinter bug in Entry widgets on OS X

A

Arnaud Delobelle

Hi all,

I'm writing a small GUI on OS X (v. 10.7.4) using Tkinter. I'm using
stock Python. It mostly works fine but there is a bug in Entry
widgets: if and Entry widget has focus and I press the UP arrow, a
"\uf700" gets inserted in the widget. If I press the DOWN arrow, a
"\uf701" gets inserted.

I'm very inexperienced with Tkinter (I've never used it before). All
I'm looking for is a workaround, i.e. a way to somehow suppress that
output.

Thanks in advance,
 
K

Kevin Walzer

I'm very inexperienced with Tkinter (I've never used it before). All
I'm looking for is a workaround, i.e. a way to somehow suppress that
output.

What are you trying to do? Navigate the focus to another widget? You
should use the tab bar for that, not the arrow key. The entry widget is
a single-line widget, and doesn't have up/down as the text widget does.
 
A

Arnaud Delobelle

What are you trying to do? Navigate the focus to another widget? You should
use the tab bar for that, not the arrow key. The entry widget is a
single-line widget, and doesn't have up/down as the text widget does.

I'm not trying to do anything. When a user presses the UP or DOWN
arrow, then a strange character is inserted in the Entry box. I'd
rather nothing happened.
 
K

Kevin Walzer

I'm not trying to do anything. When a user presses the UP or DOWN
arrow, then a strange character is inserted in the Entry box. I'd
rather nothing happened.
Why is the user doing that? If they are trying to navigate to a
different part of the interface, they need to use the tab key, not the
arrow key. It's not a multi-line text widget and shouldn't be expected
to work like one.
 
A

Arnaud Delobelle

So you make software that only behaves well when the user does what
they're supposed to do?
I agree that it is unexpected in a single line entry box but isn't the 1st
rule of user interface design to assume the user is a moron & will do
things they are not supposed to do?

Therefore invalid inputs should be handled gracefully (not just insert
random characters) which is what I think the original poster is
suggesting.

Indeed.
 
D

Dennis Lee Bieber

I agree that it is unexpected in a single line entry box but isn't the 1st
rule of user interface design to assume the user is a moron & will do
things they are not supposed to do?

Therefore invalid inputs should be handled gracefully (not just insert
random characters) which is what I think the original poster is
suggesting.

To which I'd suggest the programmer (vs the user), probably needs to
code some sort of per-character validation check... After all, there may
be situations where accepting pretty much any key-code is desired, and
if the widget filters characters before they get to the programmer level
that becomes impossible.

caveat -- I've only written one simple form using Tkinter, so what
do I know...
 
P

Peter Otten

Arnaud said:
It would be good if I could intercept the key press event and cancel its
action on the Entry widget. It's easy to intercept the key event, but I
haven't found out how to prevent the funny characters from being inserted
into the Entry widget input area.

Untested as I have no Mac:

import Tkinter as tk

def suppress(event):
if event.keycode in {111, 116}:
print "ignoring", event.keycode
return "break"
print event.keycode, "accepted"

root = tk.Tk()
entry = tk.Entry(root)
entry.bind("<Key>", suppress)
entry.pack()

root.mainloop()
I've struggled to find good tkinter
docs on the web.

For my (basic) needs I keep coming back to

http://infohost.nmt.edu/tcc/help/pubs/tkinter/
 
A

Arnaud Delobelle

Untested as I have no Mac:

import Tkinter as tk

def suppress(event):
if event.keycode in {111, 116}:
print "ignoring", event.keycode
return "break"
print event.keycode, "accepted"

root = tk.Tk()
entry = tk.Entry(root)
entry.bind("<Key>", suppress)
entry.pack()

root.mainloop()

This works fine!

return "break" is the piece of knowledge that I was missing. Thanks a
lot! In fact I lied a bit in my original message - I do use the UP
and DOWN arrows on one Entry widget for navigating its command
history. To do this I was binding the "<Up>" and "<Down>" events to a
function, which simply has to return "break" to work around the bug.
For my (basic) needs I keep coming back to

http://infohost.nmt.edu/tcc/help/pubs/tkinter/

Thanks for the link. I was using the docs on effbot which are nice
but probably incomplete (and old).

I guess I should flag up this bug but I don't even know if it's a
Python or Tk problem and have little time or expertise to investigate.
 

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

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top