+ // no, we didn't process it
+ event.Skip();
+}
+
+WXLRESULT wxTextCtrl::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+{
+ WXLRESULT lRc = wxTextCtrlBase::MSWWindowProc(nMsg, wParam, lParam);
+
+ switch ( nMsg )
+ {
+ case WM_GETDLGCODE:
+ {
+ // we always want the chars and the arrows: the arrows for
+ // navigation and the chars because we want Ctrl-C to work even
+ // in a read only control
+ long lDlgCode = DLGC_WANTCHARS | DLGC_WANTARROWS;
+
+ if ( IsEditable() )
+ {
+ // we may have several different cases:
+ // 1. normal: both TAB and ENTER are used for navigation
+ // 2. ctrl wants TAB for itself: ENTER is used to pass to
+ // the next control in the dialog
+ // 3. ctrl wants ENTER for itself: TAB is used for dialog
+ // navigation
+ // 4. ctrl wants both TAB and ENTER: Ctrl-ENTER is used to
+ // go to the next control (we need some way to do it)
+
+ // multiline controls should always get ENTER for themselves
+ if ( HasFlag(wxTE_PROCESS_ENTER) || HasFlag(wxTE_MULTILINE) )
+ lDlgCode |= DLGC_WANTMESSAGE;
+
+ if ( HasFlag(wxTE_PROCESS_TAB) )
+ lDlgCode |= DLGC_WANTTAB;
+
+ lRc |= lDlgCode;
+ }
+ else // !editable
+ {
+ // NB: use "=", not "|=" as the base class version returns
+ // the same flags in the disabled state as usual (i.e.
+ // including DLGC_WANTMESSAGE). This is strange (how
+ // does it work in the native Win32 apps?) but for now
+ // live with it.
+ lRc = lDlgCode;
+ }
+ }
+ break;
+
+#if wxUSE_MENUS
+ case WM_SETCURSOR:
+ // rich text controls seem to have a bug and don't change the
+ // cursor to the standard arrow one from the I-beam cursor usually
+ // used by them even when a popup menu is shown (this works fine
+ // for plain EDIT controls though), so explicitly work around this
+ if ( IsRich() )
+ {
+ extern wxMenu *wxCurrentPopupMenu;
+ if ( wxCurrentPopupMenu &&
+ wxCurrentPopupMenu->GetInvokingWindow() == this )
+ ::SetCursor(GetHcursorOf(*wxSTANDARD_CURSOR));
+ }
+#endif // wxUSE_MENUS
+ }
+