Opened 4 years ago

Closed 12 months ago

Last modified 12 months ago

#12808 closed defect (fixed)

wxSearchCtrl breaks tab-traversal when wxTE_PROCESS_ENTER flag is set

Reported by: jim22k Owned by:
Priority: normal Milestone:
Component: GUI-all Version: stable-latest
Keywords: Cc:
Blocked By: Blocking:
Patch: no

Description

wxSearchCtrl correctly handles tab/shift-tab for transfering focus to the next GUI element when no style flags are set. When the wxTE_PROCESS_ENTER flag is set, however, tab-traversal breaks. The flag is supposed to capture Enter and stop it from transferring focus, but it appears to also be capturing the tab.

Things that are working correctly:

  • wxSearchCtrl correctly handles the wxTE_PROCESS_TAB flag, which allows the user to enter a tab in the search box.
  • wxTextCtrl works correctly with the wxTE_PROCESS_ENTER flag, capturing Enter, but still allowing tab-traversal

So this seems to be limited to just the wxSearchCtrl handling the wxTE_PROCESS_ENTER flag.

This is on MSW (Windows 7) running wxPython 2.9.1.1. Problem also existed in wxPython 2.8.11.0

Attachments (1)

search_tab_traversal.py download (1.0 KB) - added by jim22k 4 years ago.
wxPython code showing the bug in tab-traversal

Download all attachments as: .zip

Change History (9)

Changed 4 years ago by jim22k

wxPython code showing the bug in tab-traversal

comment:1 Changed 4 years ago by neis

  • Component changed from wxMSW to GUI-all

The problem apparently exists not only on wxMSW, but also on wxGTK, see #13150.

comment:2 Changed 3 years ago by VZ

(In [68364]) Use wxNavigationEnabled<> for keyboard navigation in generic wxSearchCtrl.

Derive generic wxSearchCtrl implementation from wxNavigationEnabled<> to
ensure that TAB navigation works correctly in it. While it did work before for
search controls without wxTE_PROCESS_ENTER style (because this wasn't handled
by this control itself at all in fact), it stopped working as soon as this
style was used in wxMSW because then the navigation was implemented by
manually calling wxWindow::Navigate() and this requires wxControlContainer
support.

Use wxNavigationEnabled<> to easily add it to wxSearchCtrl.

See #12808.

comment:3 Changed 3 years ago by VZ

(In [68365]) Don't give focus to wxSearchButton when using keyboard navigation.

The search control buttons don't show that they have focus and are not meant
to have it anyhow as they are more control decorations than real buttons and
their functionality can be activated by pressing "Enter" or "Escape" already
from the keyboard. But giving it to them made TAB behave unexpectedly and
wrongly when wxSearchCtrl had focus.

Override AcceptsFocusFromKeyboard() to return false to correct this.

See #12808.

comment:4 Changed 3 years ago by VZ

(In [68367]) Exclude windows not accepting keyboard focus from GTK focus chain.

For some reason the test for AcceptsFocusFromKeyboard() wasn't done in the
correct place when constructing the GTK focus chain and even windows returning
false from it were still added to it.

Do not do this any more, this prevents the windows which are really not meant
to be focusable from keyboard (such as the pseudo-buttons in the generic
implementation of wxSearchCtrl) from gaining focus unexpectedly.

See #12808.

comment:5 Changed 3 years ago by vadz

  • Resolution set to fixed
  • Status changed from new to closed

The bug should be fixed under both MSW and GTK now, please reopen if you still see any problems and please mention under which platform do you see them.

comment:6 Changed 12 months ago by alexandrub

  • Resolution fixed deleted
  • Status changed from closed to reopened

The same happens for wxComboBox in both wx 2.8 and 2.9 (head of trunk). To reproduce check the controls sample -> wxComboBox tab. Removing wxTE_PROCESS_ENTER makes tabbing out of the combo box work.

comment:7 Changed 12 months ago by VZ

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [75210]) Don't eat TAB presses for wxComboBox with wxTE_PROCESS_ENTER in wxMSW.

Still allow to use TAB for navigation even when a wxComboBox has
wxTE_PROCESS_ENTER style.

Use the same hack for wxTextCtrl, i.e. implement the navigation ourselves as
we can't let IsDialogMessage() handle it but still get VK_ENTER key presses.

Closes #12808.

comment:8 Changed 12 months ago by VZ

(In [75216]) Don't eat TAB presses for wxComboBox with wxTE_PROCESS_ENTER in wxMSW.

Still allow to use TAB for navigation even when a wxComboBox has
wxTE_PROCESS_ENTER style.

Use the same hack for wxTextCtrl, i.e. implement the navigation ourselves as
we can't let IsDialogMessage() handle it but still get VK_ENTER key presses.

Closes #12808.

Note: See TracTickets for help on using tickets.