Bare (i.e. without any modifiers) Delete, Home and End keys are also required
by the text control itself so don't handle them as accelerators when wxTextCtrl
has focus.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69739 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxTextCtrl with wxBORDER_NONE (and possibly wxTE_READONLY) style is often used
instead of a wxStaticText to allow copying the text, so make the size of such
control the same as size of the label. This ensures that it aligns correctly
with the label vertically while before the baselines were not aligned because
a border-less text control was rendered by MSW as a label but had a too big
size.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69066 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Multiline edit control posts WM_CLOSE to its parent window when Escape key is
pressed inside it for some reason. This is unwanted as it totally bypasses our
logic for only closing the dialog when Escape is pressed if there is a
Cancel-like button in it, so suppress this behaviour by not letting the edit
control to get Escape at all.
Closes#12501.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68351 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No real changes, simply add casts to make the implicit conversions that g++
warns about when using -Wconversion explicit.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67964 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Additionally renamed wxOSX' private wxNativePrinterDC::Ok() function to IsOk().
Didn't deprecate the various Ok() functions: given the amount of changes already introduced in 3.0 a trivial one like this seems more suitable for after 3.0.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67681 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The fix applied in r64394 wasn't enough and the control could still decide to
overwrite the font used by default when non-ASCII characters were inserted
into it. To really force it to use the font we want we apparently must send it
EM_SETCHARFORMAT with SCF_ALL flag (MSDN also documents SCF_DEFAULT but it's
not clear if we should use it instead or together with SCF_ALL, for now it
doesn't seem to be necessary).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65565 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Split this overly long function into MSWSetCharFormat() and MSWSetParaFormat().
No real changes otherwise except for the use of PARAFORMAT instead of
PARAFORMAT2 if wxUSE_RICHEDIT2 is not set as it was certainly intended (but
the fact that nobody complained about this problem means that nobody must be
compiling without wxUSE_RICHEDIT2 by now so arguably we should just remove it
completely).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65564 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Set m_verRichEdit to a different value for the version 4.1 of the control as
it behaves subtly differently from the previous versions.
Also clarify that value of 2 is used for both 2.0 and 3.0 versions of the
control.
No real changes yet.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65563 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The old code used EM_LINESCROLL which could scroll too far if the caret wasn't
in the first line of the control. Instead of trying to compute the correct
number of the lines to scroll, just use WM_VSCROLL with SB_BOTTOM parameter
instead.
Closes#12123.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64571 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Using WM_SETFONT seemed to work with rich edit controls but in fact it
doesn't, it only changes the font used by the control initially apparently but
it can be reset later.
Use EM_SETCHARFORMAT which is more reliable.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64394 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxWidgets requires wchar_t for some time now; wx/chartype.h has a check
to fail complation without it. Simplify code by removing now-dead code
for the !wxUSE_WCHAR_T case.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@63991 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The best default behaviour seems to be to use white background for multiline
text controls even when they're read-only, as in previous wx versions.
Also see #11521 which could be implemented to make this configurable.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62804 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit doesn't introduce any changes in the control behaviour, it simply
moves the existing method to the base class because it is not MSW-specific.
Also implement wxTextCtrlBase::GetClassDefaultAttributes() because if a class
implements GetDefaultAttributes() it should implement it as well.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62803 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Without this, an I-beam cursor is used when a menu is shown by a rich text
control. Set the arrow cursor explicitly to work around this apparent bug in
the native control.
Closes#11314.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62718 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
2. use HandleWindowEvent() everywhere as more obvious and convenient shortcut for GetEventHandler()->ProcessEvent(); also for consistency with wxGTK where it's required
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@50329 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxTextCtrl and wxSearchCtrl now get the correct border on wxMSW, and the wxRichTextCtrl sample
also now demonstrates correct borders.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@47927 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
