Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Ensure that Enter key presses are never stolen from wxButton in wxMSW.

Browse Source 
This commit fixes the following bug: when an in-place editor control containing
an embedded button was used in wxDataViewCtrl, pressing Enter on the button
would close the editor, accepting changes, instead as (generic) wxDataViewCtrl
intercepts WXK_RETURN in its EVT_CHAR_HOOK handler. To prevent this from
happening, wxButton now handles EVT_CHAR_HOOK itself and never lets the parent
window intercept it if it's for WXK_RETURN. To ensure that normal
wxEVT_KEY_DOWN and wxEVT_CHAR are still generated in this case, wxButton
handler calls the new wxKeyEvent::DoAllowNextEvent() method that was added to
allow suppressing EVT_CHAR_HOOK only, without affecting the subsequent events.
DoAllowNextEvent() is currently only used in wxMSW but support for it was also
added to wxGTK and (both) wxOSX ports.

See #9102.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69984 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin
2011-12-11 17:03:56 +00:00
parent 91614f1aa3
commit 4cf1a9bf4a
8 changed files with 93 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
interface/wx/event.h
View File

@@ -1373,13 +1373,19 @@ enum wxKeyCategoryFlags
events and so gives the parent window an opportunity to modify the
keyboard handling of its children, e.g. it is used internally by
wxWidgets in some ports to intercept pressing Esc key in any child of a
dialog to close the dialog itself when it's pressed. If the event is
handled, i.e. the handler doesn't call wxEvent::Skip(), neither @c
wxEVT_KEY_DOWN nor @c wxEVT_CHAR events will be generated (although @c
wxEVT_KEY_UP still will be). Notice that this event is not generated
when the mouse is captured as it is considered that the window which
has the capture should receive all the keyboard events too without
allowing its parent wxTopLevelWindow to interfere with their processing.
dialog to close the dialog itself when it's pressed. By default, if
this event is handled, i.e. the handler doesn't call wxEvent::Skip(),
neither @c wxEVT_KEY_DOWN nor @c wxEVT_CHAR events will be generated
(although @c wxEVT_KEY_UP still will be), i.e. it replaces the normal
key events. However by calling the special DoAllowNextEvent() method
you can handle @c wxEVT_CHAR_HOOK and still allow normal events
generation. This is something that is rarely useful but can be required
if you need to prevent a parent @c wxEVT_CHAR_HOOK handler from running
without suppressing the normal key events. Finally notice that this
event is not generated when the mouse is captured as it is considered
that the window which has the capture should receive all the keyboard
events too without allowing its parent wxTopLevelWindow to interfere
with their processing.
@endEventTable
@see wxKeyboardState
@@ -1522,6 +1528,34 @@ public:
Returns the Y position (in client coordinates) of the event.
*/
wxCoord GetY() const;
/**
Allow normal key events generation.
Can be called from @c wxEVT_CHAR_HOOK handler to indicate that the
generation of normal events should @em not be suppressed, as it happens
by default when this event is handled.
The intended use of this method is to allow some window object to
prevent @c wxEVT_CHAR_HOOK handler in its parent window from running by
defining its own handler for this event. Without calling this method,
this would result in not generating @c wxEVT_KEY_DOWN nor @c wxEVT_CHAR
events at all but by calling it you can ensure that these events would
still be generated, even if @c wxEVT_CHAR_HOOK event was handled.
@since 2.9.3
*/
void DoAllowNextEvent();
/**
Returns @true if DoAllowNextEvent() had been called, @false by default.
This method is used by wxWidgets itself to determine whether the normal
key events should be generated after @c wxEVT_CHAR_HOOK processing.
@since 2.9.3
*/
bool IsNextEventAllowed() const;
};