+ Method called by ProcessEvent() as last resort.
+
+ This method can be overridden to implement post-processing for the
+ events which were not processed anywhere else.
+
+ The base class version handles forwarding the unprocessed events to
+ wxApp at wxEvtHandler level and propagating them upwards the window
+ child-parent chain at wxWindow level and so should usually be called
+ when overriding this method:
+ @code
+ class MyClass : public BaseClass // inheriting from wxEvtHandler
+ {
+ ...
+ protected:
+ virtual bool TryAfter(wxEvent& event)
+ {
+ if ( BaseClass::TryAfter(event) )
+ return true;
+
+ return MyPostProcess(event);
+ }
+ };
+ @endcode
+
+ @see ProcessEvent()
+ */
+ virtual bool TryAfter(wxEvent& event);
+};
+
+#endif // wxUSE_BASE
+
+#if wxUSE_GUI
+
+/**
+ Flags for categories of keys.
+
+ These values are used by wxKeyEvent::IsKeyInCategory(). They may be
+ combined via the bitwise operators |, &, and ~.
+
+ @since 2.9.1
+*/
+enum wxKeyCategoryFlags
+{
+ /// arrow keys, on and off numeric keypads
+ WXK_CATEGORY_ARROW,
+
+ /// page up and page down keys, on and off numeric keypads
+ WXK_CATEGORY_PAGING,
+
+ /// home and end keys, on and off numeric keypads
+ WXK_CATEGORY_JUMP,
+
+ /// tab key, on and off numeric keypads
+ WXK_CATEGORY_TAB,
+
+ /// backspace and delete keys, on and off numeric keypads
+ WXK_CATEGORY_CUT,
+
+ /// union of WXK_CATEGORY_ARROW, WXK_CATEGORY_PAGING, and WXK_CATEGORY_JUMP categories
+ WXK_CATEGORY_NAVIGATION
+};
+
+
+/**
+ @class wxKeyEvent
+
+ This event class contains information about key press and release events.
+
+ The main information carried by this event is the key being pressed or
+ released. It can be accessed using either GetKeyCode() function or
+ GetUnicodeKey(). For the printable characters, the latter should be used as
+ it works for any keys, including non-Latin-1 characters that can be entered
+ when using national keyboard layouts. GetKeyCode() should be used to handle
+ special characters (such as cursor arrows keys or @c HOME or @c INS and so
+ on) which correspond to ::wxKeyCode enum elements above the @c WXK_START
+ constant. While GetKeyCode() also returns the character code for Latin-1
+ keys for compatibility, it doesn't work for Unicode characters in general
+ and will return @c WXK_NONE for any non-Latin-1 ones. For this reason, it's
+ recommended to always use GetUnicodeKey() and only fall back to GetKeyCode()
+ if GetUnicodeKey() returned @c WXK_NONE meaning that the event corresponds
+ to a non-printable special keys.
+
+ While both of these functions can be used with the events of @c
+ wxEVT_KEY_DOWN, @c wxEVT_KEY_UP and @c wxEVT_CHAR types, the values
+ returned by them are different for the first two events and the last one.
+ For the latter, the key returned corresponds to the character that would
+ appear in e.g. a text zone if the user pressed the key in it. As such, its
+ value depends on the current state of the Shift key and, for the letters,
+ on the state of Caps Lock modifier. For example, if @c A key is pressed
+ without Shift being held down, wxKeyEvent of type @c wxEVT_CHAR generated
+ for this key press will return (from either GetKeyCode() or GetUnicodeKey()
+ as their meanings coincide for ASCII characters) key code of 97
+ corresponding the ASCII value of @c a. And if the same key is pressed but
+ with Shift being held (or Caps Lock being active), then the key could would
+ be 65, i.e. ASCII value of capital @c A.
+
+ However for the key down and up events the returned key code will instead
+ be @c A independently of the state of the modifier keys i.e. it depends
+ only on physical key being pressed and is not translated to its logical
+ representation using the current keyboard state. Such untranslated key
+ codes are defined as follows:
+ - For the letters they correspond to the @e upper case value of the
+ letter.
+ - For the other alphanumeric keys (e.g. @c 7 or @c +), the untranslated
+ key code corresponds to the character produced by the key when it is
+ pressed without Shift. E.g. in standard US keyboard layout the
+ untranslated key code for the key @c =/+ in the upper right corner of
+ the keyboard is 61 which is the ASCII value of @c =.
+ - For the rest of the keys (i.e. special non-printable keys) it is the
+ same as the normal key code as no translation is used anyhow.
+
+ Notice that the first rule applies to all Unicode letters, not just the
+ usual Latin-1 ones. However for non-Latin-1 letters only GetUnicodeKey()
+ can be used to retrieve the key code as GetKeyCode() just returns @c
+ WXK_NONE in this case.
+
+ To summarize: you should handle @c wxEVT_CHAR if you need the translated
+ key and @c wxEVT_KEY_DOWN if you only need the value of the key itself,
+ independent of the current keyboard state.
+
+ @note Not all key down events may be generated by the user. As an example,
+ @c wxEVT_KEY_DOWN with @c = key code can be generated using the
+ standard US keyboard layout but not using the German one because the @c
+ = key corresponds to Shift-0 key combination in this layout and the key
+ code for it is @c 0, not @c =. Because of this you should avoid
+ requiring your users to type key events that might be impossible to
+ enter on their keyboard.
+
+
+ Another difference between key and char events is that another kind of
+ translation is done for the latter ones when the Control key is pressed:
+ char events for ASCII letters in this case carry codes corresponding to the
+ ASCII value of Ctrl-Latter, i.e. 1 for Ctrl-A, 2 for Ctrl-B and so on until
+ 26 for Ctrl-Z. This is convenient for terminal-like applications and can be
+ completely ignored by all the other ones (if you need to handle Ctrl-A it
+ is probably a better idea to use the key event rather than the char one).
+ Notice that currently no translation is done for the presses of @c [, @c
+ \\, @c ], @c ^ and @c _ keys which might be mapped to ASCII values from 27
+ to 31.
+ Since version 2.9.2, the enum values @c WXK_CONTROL_A - @c WXK_CONTROL_Z
+ can be used instead of the non-descriptive constant values 1-26.
+
+ Finally, modifier keys only generate key events but no char events at all.
+ The modifiers keys are @c WXK_SHIFT, @c WXK_CONTROL, @c WXK_ALT and various
+ @c WXK_WINDOWS_XXX from ::wxKeyCode enum.
+
+ Modifier keys events are special in one additional aspect: usually the
+ keyboard state associated with a key press is well defined, e.g.
+ wxKeyboardState::ShiftDown() returns @c true only if the Shift key was held
+ pressed when the key that generated this event itself was pressed. There is
+ an ambiguity for the key press events for Shift key itself however. By
+ convention, it is considered to be already pressed when it is pressed and
+ already released when it is released. In other words, @c wxEVT_KEY_DOWN
+ event for the Shift key itself will have @c wxMOD_SHIFT in GetModifiers()
+ and ShiftDown() will return true while the @c wxEVT_KEY_UP event for Shift
+ itself will not have @c wxMOD_SHIFT in its modifiers and ShiftDown() will
+ return false.
+
+
+ @b Tip: You may discover the key codes and modifiers generated by all the
+ keys on your system interactively by running the @ref
+ page_samples_keyboard wxWidgets sample and pressing some keys in it.
+
+ @note If a key down (@c EVT_KEY_DOWN) event is caught and the event handler
+ does not call @c event.Skip() then the corresponding char event
+ (@c EVT_CHAR) will not happen. This is by design and enables the
+ programs that handle both types of events to avoid processing the
+ same key twice. As a consequence, if you do not want to suppress the
+ @c wxEVT_CHAR events for the keys you handle, always call @c
+ event.Skip() in your @c wxEVT_KEY_DOWN handler. Not doing may also
+ prevent accelerators defined using this key from working.
+
+ @note If a key is maintained in a pressed state, you will typically get a
+ lot of (automatically generated) key down events but only one key up
+ one at the end when the key is released so it is wrong to assume that
+ there is one up event corresponding to each down one.
+
+ @note For Windows programmers: The key and char events in wxWidgets are
+ similar to but slightly different from Windows @c WM_KEYDOWN and
+ @c WM_CHAR events. In particular, Alt-x combination will generate a
+ char event in wxWidgets (unless it is used as an accelerator) and
+ almost all keys, including ones without ASCII equivalents, generate
+ char events too.
+
+
+ @beginEventTable{wxKeyEvent}
+ @event{EVT_KEY_DOWN(func)}
+ Process a @c wxEVT_KEY_DOWN event (any key has been pressed). If this
+ event is handled and not skipped, @c wxEVT_CHAR will not be generated
+ at all for this key press (but @c wxEVT_KEY_UP will be).
+ @event{EVT_KEY_UP(func)}
+ Process a @c wxEVT_KEY_UP event (any key has been released).
+ @event{EVT_CHAR(func)}
+ Process a @c wxEVT_CHAR event.
+ @event{EVT_CHAR_HOOK(func)}
+ Process a @c wxEVT_CHAR_HOOK event. Unlike all the other key events,
+ this event is propagated upwards the window hierarchy which allows
+ intercepting it in the parent window of the focused window to which it
+ is sent initially (if there is no focused window, this event is sent to
+ the wxApp global object). It is also generated before any other key
+ 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. 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
+
+ @library{wxcore}
+ @category{events}
+*/
+class wxKeyEvent : public wxEvent,
+ public wxKeyboardState
+{
+public:
+ /**
+ Constructor.
+ Currently, the only valid event types are @c wxEVT_CHAR and @c wxEVT_CHAR_HOOK.
+ */
+ wxKeyEvent(wxEventType keyEventType = wxEVT_NULL);
+
+ /**
+ Returns the key code of the key that generated this event.
+
+ ASCII symbols return normal ASCII values, while events from special
+ keys such as "left cursor arrow" (@c WXK_LEFT) return values outside of
+ the ASCII range. See ::wxKeyCode for a full list of the virtual key
+ codes.
+
+ Note that this method returns a meaningful value only for special
+ non-alphanumeric keys or if the user entered a Latin-1 character (this
+ includes ASCII and the accented letters found in Western European
+ languages but not letters of other alphabets such as e.g. Cyrillic).
+ Otherwise it simply method returns @c WXK_NONE and GetUnicodeKey()
+ should be used to obtain the corresponding Unicode character.
+
+ Using GetUnicodeKey() is in general the right thing to do if you are
+ interested in the characters typed by the user, GetKeyCode() should be
+ only used for special keys (for which GetUnicodeKey() returns @c
+ WXK_NONE). To handle both kinds of keys you might write:
+ @code
+ void MyHandler::OnChar(wxKeyEvent& event)
+ {
+ wxChar uc = event.GetUnicodeKey();
+ if ( uc != WXK_NONE )
+ {
+ // It's a "normal" character. Notice that this includes
+ // control characters in 1..31 range, e.g. WXK_RETURN or
+ // WXK_BACK, so check for them explicitly.
+ if ( uc >= 32 )
+ {
+ wxLogMessage("You pressed '%c'", uc);
+ }
+ else
+ {
+ // It's a control character
+ ...
+ }
+ }
+ else // No Unicode equivalent.
+ {
+ // It's a special key, deal with all the known ones:
+ switch ( event.GetKeyCode() )
+ {
+ case WXK_LEFT:
+ case WXK_RIGHT:
+ ... move cursor ...
+ break;
+
+ case WXK_F1:
+ ... give help ...
+ break;
+ }
+ }
+ }
+ @endcode
+ */
+ int GetKeyCode() const;
+
+ /**
+ Returns true if the key is in the given key category.
+
+ @param category
+ A bitwise combination of named ::wxKeyCategoryFlags constants.
+
+ @since 2.9.1
+ */
+ bool IsKeyInCategory(int category) const;
+
+ //@{
+ /**
+ Obtains the position (in client coordinates) at which the key was pressed.
+
+ Notice that under most platforms this position is simply the current
+ mouse pointer position and has no special relationship to the key event
+ itself.
+
+ @a x and @a y may be @NULL if the corresponding coordinate is not
+ needed.
+ */
+ wxPoint GetPosition() const;
+ void GetPosition(wxCoord* x, wxCoord* y) const;
+ //@}
+
+ /**
+ Returns the raw key code for this event.
+
+ The flags are platform-dependent and should only be used if the
+ functionality provided by other wxKeyEvent methods is insufficient.
+
+ Under MSW, the raw key code is the value of @c wParam parameter of the
+ corresponding message.
+
+ Under GTK, the raw key code is the @c keyval field of the corresponding
+ GDK event.
+
+ Under OS X, the raw key code is the @c keyCode field of the
+ corresponding NSEvent.
+
+ @note Currently the raw key codes are not supported by all ports, use
+ @ifdef_ wxHAS_RAW_KEY_CODES to determine if this feature is available.
+ */
+ wxUint32 GetRawKeyCode() const;
+
+ /**
+ Returns the low level key flags for this event.
+
+ The flags are platform-dependent and should only be used if the
+ functionality provided by other wxKeyEvent methods is insufficient.
+
+ Under MSW, the raw flags are just the value of @c lParam parameter of
+ the corresponding message.
+
+ Under GTK, the raw flags contain the @c hardware_keycode field of the
+ corresponding GDK event.
+
+ Under OS X, the raw flags contain the modifiers state.
+
+ @note Currently the raw key flags are not supported by all ports, use
+ @ifdef_ wxHAS_RAW_KEY_CODES to determine if this feature is available.
+ */
+ wxUint32 GetRawKeyFlags() const;
+
+ /**
+ Returns the Unicode character corresponding to this key event.
+
+ If the key pressed doesn't have any character value (e.g. a cursor key)
+ this method will return @c WXK_NONE. In this case you should use
+ GetKeyCode() to retrieve the value of the key.
projects / wxWidgets.git / blobdiff