wxComboBox::MSWShouldPreProcessMessage() didn't take into account many
keys that must be handled in wxComboBox even if they're used as
accelerators, including plain (i.e. without Ctrl modifier) Delete, Home
and End that are used by the embedded text control, if there is one.
Fix this by reusing wxTextCtrl::MSWShouldPreProcessMessage() which
already handled these keys correctly, by moving it to wxTextEntry, which
can be used from both classes.
Also add a check for wxCB_READONLY to prevent overriding the
accelerators using the keys that the combobox doesn't need when there is
no text control in it.
Closes#19227.
Using c_str() for arguments to wxString::Printf(), Format() and
wxLogXXX() is useless since wx 2.9 days, so simply remove them.
No real changes, this is just a (long due) cleanup.
This shortcut is undocumented, but works in rich edit controls and even
in plain ones if they use SHAutoComplete(), so support it in all
controls because this is what people expect.
A single line MSW wxTextCtrl created with a value too long to fit into
it continued showing the value only partially even if its size was
subsequently increased to allow the entire value to be shown.
This apparently happens because changing the native EDIT control size
doesn't affect its (horizontal) scroll offset. Moreover, there doesn't
seem to be any way to explicitly tell the control to update it neither,
except for changing its text.
So do change its text every time its width changes, as long as it is not
visible (because visible jumps in the visible text position could be an
even worse problem than the one we're trying to solve here). This fixes
the originally reported bug at the cost of a bunch of extra calls to
DoWriteText() which should hopefully be not too expensive for single
line controls that don't typically contain that much text.
Closes#18268.
Respect wxTE_PROCESS_TAB and wxTE_PROCESS_ENTER flags even for readonly
text controls. Previously there were ignored for them due to the changes
of 080c709f70 (fix for handling TAB presses in readonly text controls,
2002-09-07), but there doesn't seem to be any good reason to do this, so
revert the changes of that commit by removing IsEditable() check from
our WM_GETDLGCODE handler.
We also need to avoid inserting TABs into readonly controls ourselves in
the default wxEVT_CHAR handler, so add a check for IsEditable() there to
compensate for the fact that these events are now received even for the
readonly controls.
This commit is best viewed ignoring whitespace-only changes.
Closes#19064.
For wxMSW text controls with wxTE_RICH2 style, calling SetFont() counts
as an undoable operation, resulting in CanUndo() returning true even if
no "real" changes have been made yet.
Fix this by resetting the undo stack after creating the control using
ITextDocument::Undo().
Unfortunately this interface is not available in MinGW-32, so this fix
can't be used with it.
Closes https://github.com/wxWidgets/wxWidgets/pull/2010Closes#17524.
Adjust the length limit before pasting to ensure that all text on
clipboard will be successfully pasted, instead of only pasting the part
of it which fits.
Add a unit test checking that this works.
Closes#4646.
The corresponding wxClipboardTextEvent was generated for Ctrl-{C,V,X}
key combinations, but not Shift-{Ins,Del} or Ctrl-Ins ones, which are
also handled by the native control by default.
This key combination is used for selecting all text, while it's also
relatively common to use it as an accelerator for some menu item.
Resolve the conflict in favour of wxTextCtrl, i.e. let it have this key
when it has focus, while still allowing to use it as an accelerator
otherwise.
The control seems to somehow react to DPI changes on its own (which is
rather mysterious as we don't forward WM_DPICHANGED to it, so it's not
really clear how does it do it, but it does) and changing its font is
worse than useless, as it's not just redundant, but also resets all the
styles used inside the control and so is really undesirable.
Hence override the just added MSWUpdateFontOnDPIChange() to do nothing
for rich edit controls, while still updating the font for the plain EDIT
ones (which is required as they don't scale correctly on their own).
Restore behaviour until c43e0fa123 and let
Enter presses in multiline text controls perform their default function
in the control instead of closing the dialog.
Make the unit test more discerning to check for this.
wxMSW always sent this event to multiline text controls, even when they
didn't have wxTE_PROCESS_ENTER style, contrary to what was documented.
Avoid sending this event unless wxTE_PROCESS_ENTER is used and add unit
tests checking that multiline text controls don't get it without this
style (but still do get it with it).
No real changes, just check for WM_CHAR inside the existing "switch"
instead of writing a separate "if" statement just for it.
Note that removing HasFlag(wxTE_PROCESS_ENTER) test shouldn't matter as
we should be only getting WM_CHAR for VK_RETURN when this flag is used.
This doesn't seem to change anything in practice, but it's more logical
to not pretend that we processed the message if we didn't do anything at
all with it.
Using the window DPI resulted in returning a twice bigger size in points
than the size really used for the windows on high-DPI monitors as,
apparently, RichEdit always uses DPI of 96 internally (tested with both
wxTE_RICH and wxTE_RICH2 in 192 DPI under Windows 10.0.16299.785).
These functions are not really useful as converting between wxFont and
LOGFONT can be done trivially by passing via wxNativeFontInfo and, in
fact, wxCreateFontFromLogFont() managed to do the conversion wrongly by
forgetting to update wxNativeFontInfo::pointSize member when changing
wxNativeFontInfo::lf.
This fixes one unit test failure after the latest changes, although not
yet the other one, see the upcoming commit for this.
When this style is specified, TAB has to be handled manually as well and
we do it by calling our Navigate() method explicitly. But for it to work
correctly we need to pretend that it's called in response to a real TAB
press by specifying FromTab flag and the code forgot to do this -- just
add the missing flag to fix it now.
In particular, this ensures that the special code handling radio buttons
in wxControlContainer::HandleOnNavigationKey() is really executed and
fixes a bug with pressing TAB on a wxTextCtrl with wxTE_PROCESS_ENTER
before a radio button group would select the first radio button of this
group instead of jumping to the currently selected button.
Closes#18392.
After bd650ec and cad2b9c, showing a popup menu in wxTextCtrl with
wxTE_RICH2 and then dismissing it without choosing a command would
result in the cursor flickering between arrow and beam cursors until
another context menu was shown.
See https://github.com/vslavik/poedit/issues/483
Fixed by checking if the popup menu is still valid (and so shown) in
the cursor handling code.
Check whether wxTextCtrl has focus using Win32 ::GetFocus() instead of
by comparing FindFocus() with "this" pointer, as the latter fails when
wxTextCtrl is part of a composite control, such as wxSearchCtrl.
This is enough to make pressing TAB in wxSearchCtrl correctly go to the
next control instead of just beeping.
Note that we could also use DoFindFocus() here, but this would be
needlessly less efficient as we don't really need to find wxWindow
corresponding to the focused HWND, as that function does. But we can't
use HasFocus() here as it wouldn't work correctly here when the focus is
on another sub-window of a composite control also containing this
wxTextCtrl.
We need to explicitly generate this event from the char hook handler as
we don't get the normal WM_CHAR for it, it is apparently intercepted by
the window proc installed by the auto-completing code, so check if
wxTE_PROCESS_ENTER is used for the text entry and call a special new
MSWProcessSpecialKey() method to do the right thing if it is.
Similarly, handle Tab presses correctly if wxTE_PROCESS_TAB is used.
Closes#12613.
