Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Tkinter bug in Entry widgets on OS X (http://www.velocityreviews.com/forums/t951641-tkinter-bug-in-entry-widgets-on-os-x.html)

Arnaud Delobelle 08-31-2012 10:18 AM

Tkinter bug in Entry widgets on OS X
 
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,

--
Arnaud

Kevin Walzer 08-31-2012 02:25 PM

Re: Tkinter bug in Entry widgets on OS X
 
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.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Arnaud Delobelle 08-31-2012 03:18 PM

Re: Tkinter bug in Entry widgets on OS X
 
On 31 August 2012 15:25, Kevin Walzer <kw@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.

--
Arnaud

Kevin Walzer 08-31-2012 03:21 PM

Re: Tkinter bug in Entry widgets on OS X
 
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.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Arnaud Delobelle 08-31-2012 07:05 PM

Re: Tkinter bug in Entry widgets on OS X
 
On 31 August 2012 16:41, Alister <alister.ware@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.


Indeed.

--
Arnaud

Dennis Lee Bieber 08-31-2012 07:30 PM

Re: Tkinter bug in Entry widgets on OS X
 
On Fri, 31 Aug 2012 15:41:01 GMT, Alister <alister.ware@ntlworld.com>
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.

caveat -- I've only written one simple form using Tkinter, so what
do I know...
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/


Peter Otten 09-01-2012 10:30 AM

Re: Tkinter bug in Entry widgets on OS X
 
Arnaud Delobelle wrote:

> On Friday, 31 August 2012, Dennis Lee Bieber wrote:
>
>> On Fri, 31 Aug 2012 15:41:01 GMT, Alister
>> <alister.ware@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"

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/


Arnaud Delobelle 09-01-2012 12:56 PM

Re: Tkinter bug in Entry widgets on OS X
 
On 1 September 2012 11:30, Peter Otten <__peter__@web.de> wrote:
> 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"
>
> 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.
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.

>
> 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.

--
Arnaud


All times are GMT. The time now is 02:34 AM.

Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.