*/
int GetId() const;
+ /**
+ Return the user data associated with a dynamically connected event handler.
+
+ wxEvtHandler::Connect() and wxEvtHandler::Bind() allow associating
+ optional @c userData pointer with the handler and this method returns
+ the value of this pointer.
+
+ The returned pointer is owned by wxWidgets and must not be deleted.
+
+ @since 2.9.5
+ */
+ wxObject *GetEventUserData() const;
+
/**
Returns @true if the event handler should be skipped, @false otherwise.
*/
*/
virtual void AddPendingEvent(const wxEvent& event);
+ /**
+ Asynchronously call the given method.
+
+ Calling this function on an object schedules an asynchronous call to
+ the method specified as CallAfter() argument at a (slightly) later
+ time. This is useful when processing some events as certain actions
+ typically can't be performed inside their handlers, e.g. you shouldn't
+ show a modal dialog from a mouse click event handler as this would
+ break the mouse capture state -- but you can call a method showing
+ this message dialog after the current event handler completes.
+
+ The method being called must be the method of the object on which
+ CallAfter() itself is called.
+
+ Notice that it is safe to use CallAfter() from other, non-GUI,
+ threads, but that the method will be always called in the main, GUI,
+ thread context.
+
+ Example of use:
+ @code
+ class MyFrame : public wxFrame {
+ void OnClick(wxMouseEvent& event) {
+ CallAfter(&MyFrame::ShowPosition, event.GetPosition());
+ }
+
+ void ShowPosition(const wxPoint& pos) {
+ if ( wxMessageBox(
+ wxString::Format("Perform click at (%d, %d)?",
+ pos.x, pos.y), "", wxYES_NO) == wxYES )
+ {
+ ... do take this click into account ...
+ }
+ }
+ };
+ @endcode
+
+ @param method The method to call.
+ @param x1 The (optional) first parameter to pass to the method.
+ @param x2 The (optional) second parameter to pass to the method.
+
+ Note that currently only up to 2 arguments can be passed.
+
+ @since 2.9.5
+ */
+ template<typename T, typename T1, ...>
+ void CallAfter(void (T::*method)(T1, ...), T1 x1, ...);
+
/**
Processes an event, searching event tables and calling zero or more suitable
event handler function(s).
be explicitly converted to the correct type which can be done using a macro
called @c wxFooEventHandler for the handler for any @c wxFooEvent.
@param userData
- Data to be associated with the event table entry.
+ Optional data to be associated with the event table entry.
+ wxWidgets will take ownership of this pointer, i.e. it will be
+ destroyed when the event handler is disconnected or at the program
+ termination. This pointer can be retrieved using
+ wxEvent::GetEventUserData() later.
@param eventSink
Object whose member function should be called. It must be specified
when connecting an event generated by one object to a member
The last ID of the identifier range to be associated with the event
handler.
@param userData
- Data to be associated with the event table entry.
+ Optional data to be associated with the event table entry.
+ wxWidgets will take ownership of this pointer, i.e. it will be
+ destroyed when the event handler is disconnected or at the program
+ termination. This pointer can be retrieved using
+ wxEvent::GetEventUserData() later.
@see @ref overview_cpp_rtti_disabled
The last ID of the identifier range to be associated with the event
handler.
@param userData
- Data to be associated with the event table entry.
+ Optional data to be associated with the event table entry.
+ wxWidgets will take ownership of this pointer, i.e. it will be
+ destroyed when the event handler is disconnected or at the program
+ termination. This pointer can be retrieved using
+ wxEvent::GetEventUserData() later.
@see @ref overview_cpp_rtti_disabled
codes.
Note that this method returns a meaningful value only for special
- non-alphanumeric keys or if the user entered a character that can be
- represented in current locale's default charset. Otherwise, e.g. if the
- user enters a Japanese character in a program not using Japanese
- locale, this method returns @c WXK_NONE and GetUnicodeKey() should be
- used to obtain the corresponding Unicode character.
+ 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
@code
void MyHandler::OnChar(wxKeyEvent& event)
{
- if ( event.GetUnicodeKey() != WXK_NONE )
+ wxChar uc = event.GetUnicodeKey();
+ if ( uc != WXK_NONE )
{
- // It's a printable character
- wxLogMessage("You pressed '%c'", event.GetUnicodeKey());
+ // 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
+ else // No Unicode equivalent.
{
// It's a special key, deal with all the known ones:
- switch ( keycode )
+ switch ( GetKeyCode() )
{
case WXK_LEFT:
case WXK_RIGHT:
//@{
/**
Obtains the position (in client coordinates) at which the key was pressed.
+
+ Notice that this position is simply the current mouse pointer position
+ and has no special relationship to the key event itself.
*/
wxPoint GetPosition() const;
void GetPosition(long* x, long* y) const;
/**
Returns the X position (in client coordinates) of the event.
+
+ @see GetPosition()
*/
wxCoord GetX() const;
/**
Returns the Y position (in client coordinates) of the event.
+
+ @see GetPosition()
*/
wxCoord GetY() const;
text was copied or cut.
@note
- These events are currently only generated by wxTextCtrl under GTK+.
- They are generated by all controls under Windows.
+ These events are currently only generated by wxTextCtrl in wxGTK and wxOSX
+ but are also generated by wxComboBox without wxCB_READONLY style in wxMSW.
@beginEventTable{wxClipboardTextEvent}
@event{EVT_TEXT_COPY(id, func)}
wxClipboardTextEvent(wxEventType commandType = wxEVT_NULL, int id = 0);
};
+/**
+ Possible axis values for mouse wheel scroll events.
+
+ @since 2.9.4
+ */
+enum wxMouseWheelAxis
+{
+ wxMOUSE_WHEEL_VERTICAL, ///< Vertical scroll event.
+ wxMOUSE_WHEEL_HORIZONTAL ///< Horizontal scroll event.
+};
/**
int GetWheelRotation() const;
/**
- Gets the axis the wheel operation concerns; @c 0 is the Y axis as on
- most mouse wheels, @c 1 is the X axis.
+ Gets the axis the wheel operation concerns.
- Note that only some models of mouse have horizontal wheel axis.
+ Usually the mouse wheel is used to scroll vertically so @c
+ wxMOUSE_WHEEL_VERTICAL is returned but some mice (and most trackpads)
+ also allow to use the wheel to scroll horizontally in which case
+ @c wxMOUSE_WHEEL_HORIZONTAL is returned.
+
+ Notice that before wxWidgets 2.9.4 this method returned @c int.
*/
- int GetWheelAxis() const;
+ wxMouseWheelAxis GetWheelAxis() const;
/**
Returns @true if the event was a mouse button event (not necessarily a button
means that the event originated from a keyboard context button event, and you
should compute a suitable position yourself, for example by calling wxGetMousePosition().
- When a keyboard context menu button is pressed on Windows, a right-click event
- with default position is sent first, and if this event is not processed, the
- context menu event is sent. So if you process mouse events and you find your
- context menu event handler is not being called, you could call wxEvent::Skip()
- for mouse right-down events.
+ Notice that the exact sequence of mouse events is different across the
+ platforms. For example, under MSW the context menu event is generated after
+ @c EVT_RIGHT_UP event and only if it was not handled but under GTK the
+ context menu event is generated after @c EVT_RIGHT_DOWN event. This is
+ correct in the sense that it ensures that the context menu is shown
+ according to the current platform UI conventions and also means that you
+ must not handle (or call wxEvent::Skip() in your handler if you do have
+ one) neither right mouse down nor right mouse up event if you plan on
+ handling @c EVT_CONTEXT_MENU event.
@beginEventTable{wxContextMenuEvent}
@event{EVT_CONTEXT_MENU(func)}
window (whether using the mouse or keyboard) and when it is done from the
program itself using wxWindow::SetFocus.
+ The focus event handlers should almost invariably call wxEvent::Skip() on
+ their event argument to allow the default handling to take place. Failure
+ to do this may result in incorrect behaviour of the native controls. Also
+ note that wxEVT_KILL_FOCUS handler must not call wxWindow::SetFocus() as
+ this, again, is not supported by all native controls. If you need to do
+ this, consider using the @ref sec_delayed_action described in wxIdleEvent
+ documentation.
+
@beginEventTable{wxFocusEvent}
@event{EVT_SET_FOCUS(func)}
Process a @c wxEVT_SET_FOCUS event.
@library{wxbase}
@category{events}
+ @section sec_delayed_action Delayed Action Mechanism
+
+ wxIdleEvent can be used to perform some action "at slightly later time".
+ This can be necessary in several circumstances when, for whatever reason,
+ something can't be done in the current event handler. For example, if a
+ mouse event handler is called with the mouse button pressed, the mouse can
+ be currently captured and some operations with it -- notably capturing it
+ again -- might be impossible or lead to undesirable results. If you still
+ want to capture it, you can do it from @c wxEVT_IDLE handler when it is
+ called the next time instead of doing it immediately.
+
+ This can be achieved in two different ways: when using static event tables,
+ you will need a flag indicating to the (always connected) idle event
+ handler whether the desired action should be performed. The originally
+ called handler would then set it to indicate that it should indeed be done
+ and the idle handler itself would reset it to prevent it from doing the
+ same action again.
+
+ Using dynamically connected event handlers things are even simpler as the
+ original event handler can simply wxEvtHandler::Connect() or
+ wxEvtHandler::Bind() the idle event handler which would only be executed
+ then and could wxEvtHandler::Disconnect() or wxEvtHandler::Unbind() itself.
+
+
@see @ref overview_events, wxUpdateUIEvent, wxWindow::OnInternalIdle
*/
class wxIdleEvent : public wxEvent
wxEventType wxEVT_HELP;
wxEventType wxEVT_DETAILED_HELP;
wxEventType wxEVT_COMMAND_TEXT_UPDATED;
+wxEventType wxEVT_COMMAND_TEXT_ENTER;
wxEventType wxEVT_COMMAND_TOOL_CLICKED;
wxEventType wxEVT_WINDOW_MODAL_DIALOG_CLOSED;
projects / wxWidgets.git / blobdiff