How to detect delete key EVT_KEY_DOWN on macbook without the simultaneous keydown of fn?

115 views
Skip to first unread message

RedHotChiliPepper

unread,
Feb 27, 2014, 3:16:05 AM2/27/14
to wxpytho...@googlegroups.com
I noticed the numbers associated with keycodes differ from operating systems.
http://www.wxpython.org/docs/api/wx.KeyEvent-class.html

For example on my Mac wx.WXK_DELETE, wx.WXK_NUMPAD_DELETE are 127 and 385 respectively.
On Windows wx.WXK_DELETE, wx.WXK_NUMPAD_DELETE are 13 and 370 respectively

Do the values associated with these variables vary only between platform or also OS version and keyboard?

Also I'm trying to detect the keydown of the "delete" button on my macbook's keyboard.

     self.fileOlv = FastObjectListViewEdit(panel, -1, style=wx.LC_REPORT|wx.SUNKEN_BORDER)
     self.fileOlv.Bind(wx.EVT_KEY_DOWN, self.printCode)
     def printCode(self,evt):
         print evt.GetKeyCode()

Pressing "delete" prints 8
Pressing "fn" prints 0
Pressing "delete" + "fn" prints 127

127 corresponds to the value of wx.WXK_DELETE on my Mac, but I could not find any keycode that corresponded to 8.  Are there any keycodes that corresponde to pressing the "delete" key on a mac in http://www.wxpython.org/docs/api/wx.KeyEvent-class.html ?

Is there a way I can detect the "delete" key being pressed down without someone having to simultaneously press the "fn" key?  I'm concerned if I bind my handler to the evt.GetKeyCode() of 8 on a Mac, that on different types of Macs the value of evt.GetKeyCode() would vary.

What is the best approach to detect events not in the keycode table?

I also wanted to add that for some reason pressing the "delete" key prints 127 instead of 8, as opposed to my above code, when I use this code snippet
import sys
import tty
tty.setcbreak(sys.stdin)
while True:
    print ord(sys.stdin.read(1))

Werner

unread,
Feb 27, 2014, 3:25:05 AM2/27/14
to wxpytho...@googlegroups.com
Hi,

On 27/02/2014 09:16, RedHotChiliPepper wrote:
> I noticed the numbers associated with keycodes differ from operating
> systems.
> http://www.wxpython.org/docs/api/wx.KeyEvent-class.html
>
> For example on my Mac wx.WXK_DELETE, wx.WXK_NUMPAD_DELETE are 127 and
> 385 respectively.
> On Windows wx.WXK_DELETE, wx.WXK_NUMPAD_DELETE are 13 and 370 respectively
>
> Do the values associated with these variables vary only between
> platform or also OS version and keyboard?
I don't know but why do you care? As long as you use the keycode names
you are fine.

Werner

RedHotChiliPepper

unread,
Feb 27, 2014, 3:32:23 AM2/27/14
to wxpytho...@googlegroups.com
I care because there is no keycode name for the "delete" keydown event on my Macbook.  However pressing both "fn" + "delete" corresponds to wx.WXK_DELETE keycode name.

I noticed on my Macbook that pressing just "delete" produces the code 8, so if I have an if statement like this:

     self.fileOlv.Bind(wx.EVT_KEY_DOWN, self.doSomething)
     def doSomething(self,evt):
         if evt.GetKeyCode() == 8:
             #do something

...and it turns out that on another type of Mac that pressing a key other than "delete" generates the keycode 8 and pressing "delete" does not generate the keycode 8 then the program would not behave the way a user would expect.

Werner

unread,
Feb 27, 2014, 3:52:46 AM2/27/14
to wxpytho...@googlegroups.com
Hi,

On 27/02/2014 09:32, RedHotChiliPepper wrote:
> I care because there is no keycode name for the "delete" keydown event
> on my Macbook. However pressing both "fn" + "delete" corresponds to
> wx.WXK_DELETE keycode name.
I guess I should have read the whole post.

This sounds like a bug to me, hopefully some Mac users will chip in.

What version of wxPython are you using?

Werner

RedHotChiliPepper

unread,
Feb 27, 2014, 4:16:54 AM2/27/14
to wxpytho...@googlegroups.com
On Mac
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)]
3.0.0.0 osx-cocoa (classic)

On Windows
2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)]
3.0.0.0 msw (classic)

Tim Roberts

unread,
Feb 27, 2014, 1:47:12 PM2/27/14
to wxpytho...@googlegroups.com
RedHotChiliPepper wrote:
>
> Also I'm trying to detect the keydown of the "delete" button on my
> macbook's keyboard.
>
> self.fileOlv = FastObjectListViewEdit(panel, -1,
> style=wx.LC_REPORT|wx.SUNKEN_BORDER)
> self.fileOlv.Bind(wx.EVT_KEY_DOWN, self.printCode)
> def printCode(self,evt):
> print evt.GetKeyCode()
>
> Pressing "delete" prints 8
> Pressing "fn" prints 0
> Pressing "delete" + "fn" prints 127
>
> 127 corresponds to the value of wx.WXK_DELETE on my Mac, but I could
> not find any keycode that corresponded to 8.

These are ASCII values (as are most of the non-magic key codes). 127 is
ASCII "rubout" (delete forward), and 8 is control-H, which is
backspace. In my experience, the Mac can be rather schizophrenic about
whether the "Delete" key means Delete or Backspace. You can even
configure things to swap the meaning, and that may be what you are
seeing here.

8 is WXK_CONTROL_H, if you have wx 2.9 or more.

The Fn key is always handled by the hardware. It doesn't generate any
key codes on its own.


> Is there a way I can detect the "delete" key being pressed down
> without someone having to simultaneously press the "fn" key? I'm
> concerned if I bind my handler to the evt.GetKeyCode() of 8 on a Mac,
> that on different types of Macs the value of evt.GetKeyCode() would vary.

Well, what is going to happen when you detect that key code? Are you
going to delete something? Or are you going to backspace over
something? The former should use 127, the latter should use 8. If the
user has configured "Delete" to send "backspace", then presumably they
will know what they did.


>
> What is the best approach to detect events not in the keycode table?

I'm not sure what that means. For the non-special keys, the keycodes
are just ASCII. The constants are just a convenient shortcut.


>
> I also wanted to add that for some reason pressing the "delete" key
> prints 127 instead of 8, as opposed to my above code, when I use this
> code snippet
> import sys
> import tty
> tty.setcbreak(sys.stdin)
> while True:
> print ord(sys.stdin.read(1))

Here, you're getting the system's TTY handling involved. The "stty"
command configures whether the key sends 8 or 127.

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

Chris Barker

unread,
Feb 28, 2014, 11:53:23 AM2/28/14
to wxpython-users
On Thu, Feb 27, 2014 at 10:47 AM, Tim Roberts <ti...@probo.com> wrote:
> Also I'm trying to detect the keydown of the "delete" button on my
> macbook's keyboard.

the key labeled delete is "delete the previous character" -- i.e. backspace)

   > Pressing "delete" prints 8
> Pressing "fn" prints 0
> Pressing "delete" + "fn" prints 127

fn+del is supposed to be "delete forward"
 
> 127 corresponds to the value of wx.WXK_DELETE on my Mac,

so that is correct and expected.

These are ASCII values (as are most of the non-magic key codes).  127 is
ASCII "rubout" (delete forward), and 8 is control-H, which is
backspace.  In my experience, the Mac can be rather schizophrenic about
whether the "Delete" key means Delete or Backspace.

no, it's not -- it's pretty consistent, and consistent with other systems -- the key labeled "delete", wich is up in the upper right of the keyboard, over the backslash key, is delete backward. fn+del is delete forward, and if you have an extended keyboard, there is another delete key  that is delete forward. The UI issue here is they are BOTH labeled "delete"!
 
 You can even
configure things to swap the meaning,

well, that can confuse things, yes -- personally I only remap the capslock key....
 
and that may be what you are
seeing here.

nope -- all is well and good, and just what is expected.

What you are looking for is WXK_BACK 

Or does the key usually used to delete backwards on other systems map to WXK_DELETE?

-Chris

 PS: It is true that the Mac has always made delete-forward a bit subtle -- for instance my wife has no idea it is even an option,  on any system...


 
--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov
Reply all
Reply to author
Forward
0 new messages