This method did the same thing as the base wxWindow class event handler.
Also remove wxPickerBase event table which became empty after removing this
method.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68368 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68367 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Simply inherit classes which need to provide TAB navigation among their
children from wxNavigationEnabled<> and remove the now unnecessary
WX_DECLARE_CONTROL_CONTAINER() macros.
Also remove WX_INIT_CONTROL_CONTAINER(), WX_DELEGATE_TO_CONTROL_CONTAINER()
and WX_EVENT_TABLE_CONTROL_CONTAINER() which are not needed neither any more.
And remove the event tables which became empty after removing the last macro.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68366 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68365 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68364 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Provide a clean, public and documented way to implement proper TAB navigation
for subwindows of a composite control: instead of using various ugly and never
documented WX_XXX_CONTROL_CONTAINER macros it is now enough to simply inherit
from wxNavigationEnabled<BaseClass> to do it.
No real changes in the code as the new class is not used anywhere yet.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68363 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Multiline edit control posts WM_CLOSE to its parent window when Escape key is
pressed inside it for some reason. This is unwanted as it totally bypasses our
logic for only closing the dialog when Escape is pressed if there is a
Cancel-like button in it, so suppress this behaviour by not letting the edit
control to get Escape at all.
Closes#12501.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68351 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Using PopState() without a previous PushState() is an error but it shouldn't
result in a crash, so add an assert guarding against it.
Closes#13197.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68344 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
MSWCommonTaskDialogInit() now (probably since r67620) always creates a
IDCANCEL button so don't create another one in wxProgressDialog code, just
ensure that the one created by that function has the correct label (either
"Cancel" or "Close").
Closes#13358.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68338 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Reusing a cached wxPaintDC should count as painting the window, otherwise we
could call DefWindowProc(WM_PAINT) if WM_PAINT was generated from inside
EVT_PAINT handler (e.g. by calling wxWindow::Update()) and this validated the
entire window and no painting was really done.
In particular this fixes redrawing of wxStyledTextCtrl which does call
Update() (completely unnecessarily AFAICS) from its EVT_PAINT handler when it
wants to fully refresh itself.
Closes#13345.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68337 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
