Keycodes captured by main pcbnew window rather than managed child windows.

[Greg Smith]

I have created wx.ComboBox in Python that can be docked in pcbnew, using AuiManager style window.

When the pane containing the ComboBox is floating, the combobox receives all the keystrokes. However, when the pane is docked with the Pcbnew window (the pane's parent), pcbnew itself steals keystrokes that are hotkeys (only two, though: lower 'o' and upper 'X'). The following shows me trying to enter 'pop' into the combobox. The 'p' key is recognized and entered, but the 'o' key is captured as a hotkey in pcbnew.

https://kicad-info.s3-us-west-2.amazonaws.com/original/2X/f/f4296ab59415a87ffc7c38692ff949da37632fb2.png

Further testing reveals something very strange:

Only lowercase 'o' and capital 'X' are captured by the pcbnew frame when focus is on the wx ComboBox docked in the pcbnew frame..
(and they are recognized as 'Add footprint' and 'Add track' respectively)

When the frame has focus, capital 'O' doesn't appear to do anything, while lowercase 'x' activates 'Add track'.

All other letter characters (lower and upper case) are ignored while focus is on the docked wx combobox.

This happens with OpenGL canvas and Legacy canvas.

Application: kicad
Version: (2017-08-27 revision e3c64f1f0)-makepkg, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    Curl: 7.54.1
    KiCad compiler: GCC 7.1.0 with C++ ABI 1011
Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON

[jean-pierre charras (jp-charras)]

I am not sure this is a bug:
this is more the expected behavior of accelerators keys:
o and X are not really captured by the main frame: they are accelerators keys of 2 submenus, and act as accelerators.
Therefore because they are "captured" by the relevant menus, they are not sent to other menu items.

When your pane is not docked, it is shown in a miniframe, therefore the main frame does not have the focus, and the menuitems do not capture their accelerator keys.

You cannot have both accelerator keys (captured by the relevant menus) and all keys available in widgets managed by the same frame
(at least on Windows. I am thinking it is not true on other platforms, but each platform has a specific behavior for that).

[Greg Smith (gmsmith)]

It seems strange that those are the only two characters that are captured. And the combination of upper and lower case makes a difference. Are there only two Accelerators?

[jean-pierre charras (jp-charras)]

By opening submenus of the main menu, you can see accelerators in use.