How to capture ALL keyboard hits?

I do not understand why the following code (snippet) fails to capture some of my keyboard keys (HP Pavilion laptop):

import wx
import sys
import locale # To handle Swedish KB
locale.setlocale(locale.LC_ALL,'' )
print 'Python version: %s\n' %sys.version
print 'wxPython version: %s\n' %wx.version()
...
self.Bind(wx.EVT_KEY_DOWN, self.onKeyDown)
...
def onKeyDown(self,evt):
     keycode = evt.GetKeyCode()
     print keycode
     ...

This does capture many of the keys; but, fails to capture the arrow keys (for example).
How can I capture ALL KEY hit?

Note:
  * Python version: 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)]
  * wxPython version: 2.8.12.1 (msw-unicode)
  * Windows 7

What is self? Does it have the keyboard focus? What are its parent, and grandparents up to the top-level window? What styles are they each created with? (See how much easier it would be if you provided a complete runnable sample with your questions? http://wiki.wxpython.org/MakingSampleApps)

···

On 2/14/12 12:35 PM, Virgil Stokes wrote:

I do not understand why the following code (snippet) fails to capture
some of my keyboard keys (HP Pavilion laptop):

import wx
import sys
import locale # To handle Swedish KB
locale.setlocale(locale.LC_ALL,'' )
print 'Python version: %s\n' %sys.version
print 'wxPython version: %s\n' %wx.version()
...
self.Bind(wx.EVT_KEY_DOWN, self.onKeyDown)
...
def onKeyDown(self,evt):
keycode = evt.GetKeyCode()
print keycode
...

This does capture many of the keys; but, fails to capture the arrow keys
(for example).
How can I capture ALL KEY hit?

--
Robin Dunn
Software Craftsman
http://wxPython.org

Ok Robin,
You make a good point. But, IMHO if these pieces of code can capture many of my keys then this implies that: 1) self is not that important, 2) has keyboard focus else it would not capture any of the keys, etc.

But, again, I am not an expert. And the complete piece of code which this is taken from is very large and would be awkward to post and discuss.
I have done a lot of experimenting with many variations on the code, and tried to post code that I thought was relevant to my problem.

I will continue to work on this problem myself --- if find a solution then I will post it.

···

On 2012-02-14 22:04, Robin Dunn wrote:

On 2/14/12 12:35 PM, Virgil Stokes wrote:

I do not understand why the following code (snippet) fails to capture
some of my keyboard keys (HP Pavilion laptop):

import wx
import sys
import locale # To handle Swedish KB
locale.setlocale(locale.LC_ALL,'' )
print 'Python version: %s\n' %sys.version
print 'wxPython version: %s\n' %wx.version()
...
self.Bind(wx.EVT_KEY_DOWN, self.onKeyDown)
...
def onKeyDown(self,evt):
keycode = evt.GetKeyCode()
print keycode
...

This does capture many of the keys; but, fails to capture the arrow keys
(for example).
How can I capture ALL KEY hit?

What is self? Does it have the keyboard focus? What are its parent, and grandparents up to the top-level window? What styles are they each created with? (See how much easier it would be if you provided a complete runnable sample with your questions? http://wiki.wxpython.org/MakingSampleApps)

Ok I found a solution,
Inheritance from wx.Window rather than wx.Panel, in the class where I was trying to detect what key was hit, fixed the problem.
Unfortunately, I can not explain why this works; but, perhaps someone else in this group can --- this information would be welcomed.

···

On 2012-02-14 22:22, Virgil Stokes wrote:

On 2012-02-14 22:04, Robin Dunn wrote:

On 2/14/12 12:35 PM, Virgil Stokes wrote:

I do not understand why the following code (snippet) fails to capture
some of my keyboard keys (HP Pavilion laptop):

import wx
import sys
import locale # To handle Swedish KB
locale.setlocale(locale.LC_ALL,'' )
print 'Python version: %s\n' %sys.version
print 'wxPython version: %s\n' %wx.version()
...
self.Bind(wx.EVT_KEY_DOWN, self.onKeyDown)
...
def onKeyDown(self,evt):
keycode = evt.GetKeyCode()
print keycode
...

This does capture many of the keys; but, fails to capture the arrow keys
(for example).
How can I capture ALL KEY hit?

What is self? Does it have the keyboard focus? What are its parent, and grandparents up to the top-level window? What styles are they each created with? (See how much easier it would be if you provided a complete runnable sample with your questions? http://wiki.wxpython.org/MakingSampleApps)

Ok Robin,
You make a good point. But, IMHO if these pieces of code can capture many of my keys then this implies that: 1) self is not that important, 2) has keyboard focus else it would not capture any of the keys, etc.

But, again, I am not an expert. And the complete piece of code which this is taken from is very large and would be awkward to post and discuss.
I have done a lot of experimenting with many variations on the code, and tried to post code that I thought was relevant to my problem.

I will continue to work on this problem myself --- if find a solution then I will post it.

You are going about it with the wrong approach, IMHO. The way to resolve
pretty well *any* programming problem (not just Python or wxPython) is to
keep reducing.

···

On Tue, 14 Feb 2012 23:36:48 +0100, Virgil Stokes wrote:

On 2012-02-14 22:22, Virgil Stokes wrote:

On 2012-02-14 22:04, Robin Dunn wrote:

On 2/14/12 12:35 PM, Virgil Stokes wrote:

I do not understand why the following code (snippet) fails to capture
some of my keyboard keys (HP Pavilion laptop):

import wx import sys import locale # To handle Swedish KB
locale.setlocale(locale.LC_ALL,'' )
print 'Python version: %s\n' %sys.version print 'wxPython version:
%s\n' %wx.version()
...
...
self.Bind(wx.EVT_KEY_DOWN, self.onKeyDown)
...
...
def onKeyDown(self,evt):
keycode = evt.GetKeyCode()
print keycode ...
...

This does capture many of the keys; but, fails to capture the arrow
keys (for example).
How can I capture ALL KEY hit?

What is self? Does it have the keyboard focus? What are its parent,
and grandparents up to the top-level window? What styles are they
each created with? (See how much easier it would be if you provided a
complete runnable sample with your questions?
http://wiki.wxpython.org/MakingSampleApps)

Ok Robin,
You make a good point. But, IMHO if these pieces of code can capture
many of my keys then this implies that: 1) self is not that important,
2) has keyboard focus else it would not capture any of the keys, etc.

But, again, I am not an expert. And the complete piece of code which
this is taken from is very large and would be awkward to post and
discuss.
I have done a lot of experimenting with many variations on the code,
and tried to post code that I thought was relevant to my problem.

I will continue to work on this problem myself --- if find a solution
then I will post it.

Ok I found a solution,
Inheritance from wx.Window rather than wx.Panel, in the class where I
was trying to detect what key was hit, fixed the problem. Unfortunately,
I can not explain why this works; but, perhaps someone else in this
group can --- this information would be welcomed.

Virgil Stokes wrote:

Ok I found a solution,
Inheritance from wx.Window rather than wx.Panel, in the class where I
was trying to detect what key was hit, fixed the problem.
Unfortunately, I can not explain why this works; but, perhaps someone
else in this group can --- this information would be welcomed.

The reason is subtle. The panel uses dialog semantics, so that things
like the tab work to get you from field to field. With dialog
semantics, there are key filters in the message path already. Some of
those key filters do not pass through the keys after they have processed
them.

wx.Window does not use dialog semantics, so you can't tab from field to
field, but you can intercept the keys yourself.

···

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

Thanks Tim,
It seems to me that one should have more control over key filters from within wx.Panel and not need to go to a higher class. But, perhaps this is rather difficult. Is this sort of problem also present in the C/C++ implementations of wxPython?

···

On 15-Feb-2012 01:30, Tim Roberts wrote:

Virgil Stokes wrote:

Ok I found a solution,
Inheritance from wx.Window rather than wx.Panel, in the class where I
was trying to detect what key was hit, fixed the problem.
Unfortunately, I can not explain why this works; but, perhaps someone
else in this group can --- this information would be welcomed.

The reason is subtle. The panel uses dialog semantics, so that things
like the tab work to get you from field to field. With dialog
semantics, there are key filters in the message path already. Some of
those key filters do not pass through the keys after they have processed
them.

wx.Window does not use dialog semantics, so you can't tab from field to
field, but you can intercept the keys yourself.

Sorry Walter,
But I do not understand what you mean by "keep reducing" --- could you explain this please.

···

On 15-Feb-2012 01:29, Walter Hurry wrote:

On Tue, 14 Feb 2012 23:36:48 +0100, Virgil Stokes wrote:

On 2012-02-14 22:22, Virgil Stokes wrote:

On 2012-02-14 22:04, Robin Dunn wrote:

On 2/14/12 12:35 PM, Virgil Stokes wrote:

I do not understand why the following code (snippet) fails to capture
some of my keyboard keys (HP Pavilion laptop):

import wx import sys import locale # To handle Swedish KB
locale.setlocale(locale.LC_ALL,'' )
print 'Python version: %s\n' %sys.version print 'wxPython version:
%s\n' %wx.version()
...
self.Bind(wx.EVT_KEY_DOWN, self.onKeyDown)
...
def onKeyDown(self,evt):
keycode = evt.GetKeyCode()
print keycode ...
...

This does capture many of the keys; but, fails to capture the arrow
keys (for example).
How can I capture ALL KEY hit?

What is self? Does it have the keyboard focus? What are its parent,
and grandparents up to the top-level window? What styles are they
each created with? (See how much easier it would be if you provided a
complete runnable sample with your questions?
http://wiki.wxpython.org/MakingSampleApps)

Ok Robin,
You make a good point. But, IMHO if these pieces of code can capture
many of my keys then this implies that: 1) self is not that important,
2) has keyboard focus else it would not capture any of the keys, etc.

But, again, I am not an expert. And the complete piece of code which
this is taken from is very large and would be awkward to post and
discuss.
I have done a lot of experimenting with many variations on the code,
and tried to post code that I thought was relevant to my problem.

I will continue to work on this problem myself --- if find a solution
then I will post it.

Ok I found a solution,
Inheritance from wx.Window rather than wx.Panel, in the class where I
was trying to detect what key was hit, fixed the problem. Unfortunately,
I can not explain why this works; but, perhaps someone else in this
group can --- this information would be welcomed.

You are going about it with the wrong approach, IMHO. The way to resolve
pretty well *any* programming problem (not just Python or wxPython) is to
keep reducing.

Virgil Stokes wrote:

It seems to me that one should have more control over key filters from within
wx.Panel and not need to go to a higher class. But, perhaps this is rather
difficult. Is this sort of problem also present in the C/C++ implementations of
wxPython?

Yes. More than that, the same problem exists in Windows dialog apps
written directly to the Win32 API. It's an artifact of the operating
system design, not the framework.

···

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

Thanks Tim,
How long have you been working with wxPython, and what is the origin/meaning of the "wx"?

···

On 15-Feb-2012 18:46, Tim Roberts wrote:

Virgil Stokes wrote:

It seems to me that one should have more control over key filters from within
wx.Panel and not need to go to a higher class. But, perhaps this is rather
difficult. Is this sort of problem also present in the C/C++ implementations of
wxPython?

Yes. More than that, the same problem exists in Windows dialog apps
written directly to the Win32 API. It's an artifact of the operating
system design, not the framework.

...

and what is the origin/meaning of the "wx"?

http://en.wikipedia.org/wiki/WxWidgets

wxPython is one of many wrappers of the wxWidgets toolkit.

Werner

···

On 15/02/2012 19:14, Virgil Stokes wrote:

One of the jobs of the wx.Panel class is to implement tab navigation between child widgets. To do this it needs to capture the events for navigation keys, and since there can be subtle differences between platforms for this we try to let the platform APIs handle this behavior. Unfortunately that means that the navigation keys are even harder to intercept. You can turn this off by not using the default wx.TAB_TRAVERSAL style. If the widget with the focus is a native widget and you're wanting to get arrow key events from it then you may want to try using the wx.WANTS_CHARS style for that widget.

···

On 2/15/12 12:30 AM, Virgil Stokes wrote:

On 15-Feb-2012 01:30, Tim Roberts wrote:

Virgil Stokes wrote:

Ok I found a solution,
Inheritance from wx.Window rather than wx.Panel, in the class where I
was trying to detect what key was hit, fixed the problem.
Unfortunately, I can not explain why this works; but, perhaps someone
else in this group can --- this information would be welcomed.

The reason is subtle. The panel uses dialog semantics, so that things
like the tab work to get you from field to field. With dialog
semantics, there are key filters in the message path already. Some of
those key filters do not pass through the keys after they have processed
them.

wx.Window does not use dialog semantics, so you can't tab from field to
field, but you can intercept the keys yourself.

Thanks Tim,
It seems to me that one should have more control over key filters from
within wx.Panel and not need to go to a higher class. But, perhaps this
is rather difficult. Is this sort of problem also present in the C/C++
implementations of wxPython?

--
Robin Dunn
Software Craftsman
http://wxPython.org

It originally meant "Windows and Xview", which were the first two platforms that were targeted by the library. (Xview was a commonly used library back then which was built on top of X-Windows.)

BTW, wxWidgets is 20 years old this year, which is likely older than a good percentage of its users :slight_smile:

···

On 2/15/12 10:14 AM, Virgil Stokes wrote:

On 15-Feb-2012 18:46, Tim Roberts wrote:

Virgil Stokes wrote:

It seems to me that one should have more control over key filters
from within
wx.Panel and not need to go to a higher class. But, perhaps this is
rather
difficult. Is this sort of problem also present in the C/C++
implementations of
wxPython?

Yes. More than that, the same problem exists in Windows dialog apps
written directly to the Win32 API. It's an artifact of the operating
system design, not the framework.

Thanks Tim,
How long have you been working with wxPython, and what is the
origin/meaning of the "wx"?

--
Robin Dunn
Software Craftsman
http://wxPython.org

Virgil Stokes wrote:

Thanks Tim,
How long have you been working with wxPython, and what is the origin/meaning of
the "wx"?

My day job is actually writing drivers. I've been doing Windows drivers
and Windows applications for just over 20 years, so I'm pretty
comfortable with the API. That, in part, leads me to have a deep
appreciation for how much these frameworks are really doing for us.

I got into Python fairly early, while it was still version 1, in the
late 1990s. It drew me away from Delphi, which had previously been my
language of choice. I got into wxPython just at the turn of the century.

The wx project, originally called "wxWindows" until Microsoft
complained, was designed from the start to be cross-platform, supporting
both Windows and X. Hence, "wx".

···

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

Thanks for the info Robin and your good work on wxPython. Are there any plans to improve the documentation of the API for wxPython?

···

On 2012-02-15 19:52, Robin Dunn wrote:

On 2/15/12 10:14 AM, Virgil Stokes wrote:

On 15-Feb-2012 18:46, Tim Roberts wrote:

Virgil Stokes wrote:

It seems to me that one should have more control over key filters
from within
wx.Panel and not need to go to a higher class. But, perhaps this is
rather
difficult. Is this sort of problem also present in the C/C++
implementations of
wxPython?

Yes. More than that, the same problem exists in Windows dialog apps
written directly to the Win32 API. It's an artifact of the operating
system design, not the framework.

Thanks Tim,
How long have you been working with wxPython, and what is the
origin/meaning of the "wx"?

It originally meant "Windows and Xview", which were the first two platforms that were targeted by the library. (Xview was a commonly used library back then which was built on top of X-Windows.)

BTW, wxWidgets is 20 years old this year, which is likely older than a good percentage of its users :slight_smile:

Virgil Stokes wrote:

Thanks Tim,
How long have you been working with wxPython, and what is the origin/meaning of
the "wx"?

My day job is actually writing drivers. I've been doing Windows drivers
and Windows applications for just over 20 years, so I'm pretty
comfortable with the API. That, in part, leads me to have a deep
appreciation for how much these frameworks are really doing for us.

I got into Python fairly early, while it was still version 1, in the
late 1990s. It drew me away from Delphi, which had previously been my
language of choice.

Mine too! I was very fond of Borland's software and I wrote my first OOP's in Delphi --- a great IDE for Pascal.

  I got into wxPython just at the turn of the century.

The wx project, originally called "wxWindows" until Microsoft
complained, was designed from the start to be cross-platform, supporting
both Windows and X. Hence, "wx".

Good to know, and thanks for the info.

···

On 2012-02-15 20:00, Tim Roberts wrote:

One of the goals of Project Phoenix is to improve the documentation of wxPython. Once Project Phoenix is complete, the documentation will be easier to update and improve upon. At least that’s my understanding of it.

···

Mike Driscoll
www.mousevspython.com