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.
> 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.
On 31 August 2012 15:25, Kevin Walzer <k...@codebykevin.com> wrote:
> On 8/31/12 6:18 AM, Arnaud Delobelle wrote:
>> 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.
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.
> 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.
On Fri, 31 Aug 2012 11:21:14 -0400, Kevin Walzer wrote:
> On 8/31/12 11:18 AM, Arnaud Delobelle wrote:
>> 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.
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.
On 31 August 2012 16:41, Alister <alister.w...@ntlworld.com> wrote:
> On Fri, 31 Aug 2012 11:21:14 -0400, Kevin Walzer wrote:
>> On 8/31/12 11:18 AM, Arnaud Delobelle wrote:
>>> 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.
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.
Arnaud Delobelle wrote:
> On Friday, 31 August 2012, Dennis Lee Bieber wrote:
>> On Fri, 31 Aug 2012 15:41:01 GMT, Alister
>> <alister.w...@ntlworld.com<javascript:;>
>> declaimed the following in gmane.comp.python.general:
>> > 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.
> 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"
> Arnaud Delobelle wrote:
>> 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"
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.
On other Entry widgets, I just bind "<Up>" and "<Down>" to a suppress
function which simply returns "break".
>> I've struggled to find good tkinter
>> docs on the web.
In article <k1qhgn$me...@dont-email.me>,
Kevin Walzer <k...@codebykevin.com> wrote:
> On 8/31/12 6:18 AM, Arnaud Delobelle wrote:
> > 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.
Based on other replies it looks as if the OP found a way to intercept the event with suitable binding.
But I can answer the "why": on Mac OS X in a one-line text box up-arrow should move the cursor to the beginning and down-arrow to the end. That's standard behavior.
In any case I can't imagine ever wanting to see special chars get added when arrow keys are pressed. The default behavior of the Entry widget is unfortunate.
