It seems unlikely that we're ever going to need this function in any
other classes inheriting from wxTextEntry (i.e. wxComboBox) and both
existing implementations are for wxTextCtrl only, so define this
function there.
If really necessary, we can always lower it to wxTextEntry later, while
moving it in the other direction wouldn't be easily possible due to
compatibility concerns.
This commit is best viewed with git --color-moved option.
This allows each control have its own undo history, independent of the
other ones, as expected by the wx API, rather than using an undo manager
shared by all controls in the same TLW.
Previously the edge event ContentLoading was used which was
triggered earlier than DOMContentLoaded. This event wasn't
available in earlier SDK versions.
Minimum required SDK version is now:
1.0.705.50 (Released 2021-01-25)
Fixes#19202
See https://github.com/wxWidgets/wxWidgets/pull/2468
It doesn't cost us anything to define the compatible names, and there is
no real advantage for the existing application code in using the new
names, so define them without WXWIN_COMPATIBILITY_X_Y checks around
them, to avoid forcing unnecessary changes in the application code when
upgrading to wx 3.2.0.
This commit is best viewed ignoring whitespace-only changes.
The same value of 80px was used in both the generic and MSW versions of
wxListCtrl, so introduce a symbolic name for it and define it only once,
similarly to how it's already done for wxDVC_DEFAULT_WIDTH and
WXGRID_DEFAULT_COL_WIDTH.
No real changes.
Under MSW creating a wxSpinCtrl with a range of, say, 1..10 and the
default initial value of 0 sets its initial value to 1 (i.e. the closest
valid value) as expected, but the generic version still set it to the
invalid value of 0, which was unexpected, inconsistent and not useful.
Fix the generic version to follow MSW behaviour now and add a test
checking for this.
No real changes, just make it possible to use these constants without
including the entire wx/intl.h.
Note that the existing headers including wx/intl.h need to keep
including it, unfortunately, as not doing it any longer would break
compilation of any code including them which relies on _() or
wxGetTranslation() being defined after including e.g. wx/dc.h. This was,
of course, never guaranteed, but in practice it worked for a very long
time, so don't break it now.
This commit is best viewed with --color-moved git option.
This was removed in 415f080c80 (Split wxGrid RANGE_SELECT event into
SELECTING and SELECTED, 2020-07-27) without preserving it for
compatibility. Do define it now, just as it was done for the non-CMD
equivalent of this macro EVT_GRID_RANGE_SELECT.
Also update the documentation to fix a typo from e2f316b19d (Mention
that wxEVT_GRID_RANGE_SELECT{ED,ING} are new in 3.1.5, 2020-08-18).
This will allow using this class in the library code too.
No real changes yet, this is a pure refactoring.
This commit is best viewed using git --color-moved option.
The wxrc program does not depend on the GUI libraries, but only on
the base and XML libraries, so make it possible to build it in non-GUI
builds too.
Closes https://github.com/wxWidgets/wxWidgets/pull/2419
Use 2 separate functions instead to make the code more clear, as passing
false for indicate the refresh shouldn't be done was quite confusing.
Also get rid of a separate RefreshAll() which was called only from
RecalculatePositions().
No real changes.
Fix
'friend' keyword needs 'class'
error introduced by 035c29e6a2 (Make wxRescaleCoord() safer by requiring
explicitly using From/To, 2021-07-13) which broke the build with gcc
4.4.7 used under CentOS 6.
Closes https://github.com/wxWidgets/wxWidgets/pull/2450
If derived class sets clipping region in a legitimate way by call to
DoSetClippingRegion() instead of directly storing logical coordinates
of the box in the internal variables we can store coordinates in
device units to determine final logical coordinates more reliably even
in case when coordinate transformations were applied to DC
in the meantime.
Clipping box coordinates should be stored internally in device units
to be independent on changes of logical coordinates made between calls
to wxDCImpl::DoSetClippingRegion().
These stored coordinates should be converted on demand to the current
logical units on call to wxDCImpl::DoGetClippingRect().
New <g> container element should be created every time
the actual transformation is changed and that's why
the flag should be set in ComputeScaleAndOrigin().
It was impossible to give focus to the actual web view in wxWebViewEdge
by keyboard navigation or programmatically with wxWebViewEdge::SetFocus().
Fix it by calling CoreWebView2Controller::MoveFocus() in the wxWebViewEdge's
wxEVT_SET_FOCUS handler.
Closes https://github.com/wxWidgets/wxWidgets/pull/2444
We accidentally ended up with two functions doing the same thing, since
DoGetBorderSize() was added in 743b426605 (Added DoGetClientBestSize()
and use it for a couple of controls in wxMSW., 2009-06-22), as we
already had GetWindowBorderSize() added even earlier in 333d70525c
(added wxWindow::GetWindowBorderSize(), 2006-11-25), so remove the
redundant non-public function and use GetWindowBorderSize() everywhere.
This does change the behaviour of GetWindowBorderSize() in wxMSW, wxGTK
and wxUniv, as it now does what DoGetBorderSize() used to do, but this
should be an improvement, as DoGetBorderSize() implementation was more
precise.
Using non-PCRE system regex library, which was the only build variant
when wxHAS_REGEX_ADVANCED was not defined, is not supported any more, so
simplify the code by not testing for it.
Adjust the tests and document the incompatibilities with the previously
used regex syntax.
In this commit the use of PCRE is conditional on wxUSE_PCRE which is
never defined as 1 yet, so the new code is still disabled.
This function was broken when it was called for a window which was not
the window the sizer was associated with since the recent (pre-3.1.5)
changes trying to work around the problem with the initial windows size
when using GTK 3, see 9c0a8be1dc (Merge branch 'gtk-initial-size',
2021-04-13).
Fix it by passing the sizer to use for calculating the size explicitly
to WXSetInitialFittingClientSize() when we have it, and only falling
back on the window's own sizer if we don't.
Closes#19170.
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.
Simplify wxComboCtrl code by always using wxPopupTransientWindow if it's
available instead of various platform-specific workarounds that
shouldn't be needed any longer.
See https://github.com/wxWidgets/wxWidgets/pull/2423
Move definitions of wxTE_XXX flags that can be used with the controls
other than wxTextCtrl to wx/defs.h, as wxFormBuilder generates code
using them without including wx/textctrl.h, so that this code doesn't
compile.
This was already addressed in 2970f22a89 (Include <wx/textctrl.h> from
<wx/combobox.h> for compatibility., 2012-03-25) for wxComboBox, but it
also happened for wxSpinCtrl, so fix it once and for all by always
defining these styles.
This partially reverts the changes done in c57e33394c ([...] moved
wxTextCtrl-specific stuff from defs.h/event.h to textctrl.h, 2001-07-29)
as it turns out, 20 years later, that this wasn't such a great idea.
See #14132.
Closes#19225.
Use the same scaling function as elsewhere instead of using
ceil/floor().
Provide wxRescaleCoordWithFrom specialization for int to allow using it
with just single coordinates too.
They're probably not that useful in application code, which should just
use wxDPIChangedEvent::Scale() instead, so move them to a private
header instead of making them part of the public API.
This is more concise and less error-prone than multiplying/dividing DPI
values manually.
No real changes except, maybe, in wxSlider code where the rounding was
done differently before for some reason.
