Add two step creation to wxTextEntryDialog.

[wxWidgets.git] / interface / wx / event.h

diff --git a/interface/wx/event.h b/interface/wx/event.h
index 766e074b2243c2dae2ebbd050aac599f8f4e330b..f471d6cd21295f7c97caa8bf09f027d9f9f342a2 100644 (file)
--- a/interface/wx/event.h
+++ b/interface/wx/event.h
@@ -1393,11 +1393,11 @@ public:
         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
@@ -1406,12 +1406,23 @@ public:
         @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 ( GetKeyCode() )
@@ -1444,6 +1455,9 @@ public:
     //@{
     /**
         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;
@@ -1502,11 +1516,15 @@ public:
 
     /**
         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;
 
@@ -2843,11 +2861,15 @@ public:
     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)}
@@ -4543,6 +4565,7 @@ wxEventType wxEVT_COMMAND_ENTER;
 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;