Don't generate wxEVT_CHAR_HOOK events while the mouse is captured.
This prevents the parent TLW from interfering with the keyboard handling of the window that captured the mouse which very often needs Escape for itself to cancel the capture. In particular, this fixes the problems with Escape closing the entire dialog containing the controls instead of closing just the combobox drop down or a popup menu in wxMSW. Also modify wxGTK for consistency and update the documentation. Closes #12952. git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67191 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -1310,8 +1310,11 @@ enum wxKeyCategoryFlags
|
||||
keyboard events are generated giving the parent window the opportunity
|
||||
to intercept all the keyboard entry. If the event is handled, i.e. the
|
||||
handler doesn't call wxEvent::Skip(), no further keyboard events are
|
||||
generated. Notice that this event is currently not generated by
|
||||
wxOSX/Cocoa port.
|
||||
generated. 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. Also please note
|
||||
that currently this event is not generated by wxOSX/Cocoa port.
|
||||
@endEventTable
|
||||
|
||||
@see wxKeyboardState
|
||||
|
Reference in New Issue
Block a user