Return true, not false, from EnableProofCheck() when turning the checks
off in wxMSW.
Also fix wxTextProofOptions::IsSpellCheckEnabled() return value in
wxGTK, where EnableProofCheck() already returned the correct value but
only due to a combination of two bugs.
Closes#23831, #23832.
This is identical to 44e9218e03 (Don't always increase height in
DoGetSizeFromTextSize(), 2023-02-02) for wxGTK and ensures that we don't
make the returned height too big when a valid height is specified on
input.
Supporting XP requires too many hacks, and while it wouldn't be very
difficult to support Vista as long as we support Windows 7, it's still
not worth it because nobody uses this system anyhow.
Remove most of XP-specific code and don't use wxDynamicLibrary for using
the functions not present in it any longer.
Don't use <wspiapi.h> neither as we shouldn't use it any more.
Update some comments to not mention Windows versions not supported any
longer and also remove mentions of "Vista and newer Windows versions"
from the documentation as this is now always the case.
This commit is best viewed ignoring whitespace-only changes.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
When inheriting from std::streambuf, as is the case by default, and
creating wxTextCtrl in the application (as is common) and destroying it
in the library (as is even more so, as it's typically done when the
parent window is destroyed), having inline constructor but not inline
destructor apparently results in std::locale, which is part of
std::streambuf, to be allocated and destroyed using different heaps or
something similar when using TDM-GCC libstdc++, as destroying
std::locale inside the library corrupts the heap and results in crashes
when the next std::locale object is destroyed -- i.e. creating, and then
destroying, more than one wxTextCtrl results in a crash.
Work around this by moving the constructors out of line, as this is
sufficient to avoid the problem, even if it's exact causes are not
exactly clear.
This commit is best viewed with Git --color-moved option.
See #22639.
When creating a wxTextCtrl with the initial text which is too long to
fit into a plain EDIT, automatically create RICHEDIT instead.
This is not perfect, e.g. it still doesn't make calling SetValue() with
long text later work, but it seems to still be preferable to failing to
create the window completely, which results in many other more difficult
to diagnose problems later.
This is more consistent with EnableProofCheck() and allows to retrieve
the current state of grammar checking under macOS, which can be checked
by user and so can be useful to know.
Remove a separate "bool enable" argument of EnableProofCheck() and use
wxTextProofOptions::IsSpellCheckingEnabled() to decide whether the
checks should be enabled or disabled.
Also remove wxTextProofOptions ctor and provide named static factory
functions for creating the objects of this class with clearly defined
meaning.
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.
