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.
This wrapper simply combines the calls to MakeAbsolute() and
GetFullPath(), but using it results in shorter and more clear code, so
it seems to be worth having.
Using wxFileName::Normalize() with default flags could be surprising and
result in bugs in the code, as shown by our own wrong use of it in
wxFileSystemWatcher corrected in the previous commit.
Deprecate using it without any flags and recommend using MakeAbsolute()
instead.
Also improve the related parts of the documentation.
Unlike the parent commit, this one does change the behaviour by not
applying some normalizations any more, but these changes are correct,
i.e. we really don't need to call Normalize(), which expands environment
variables in the file names by default, here and just want to make the
file paths absolute.
In particular, this fixes the problem of mangling file names containing
dollar signs in wxFileSystemWatcher.
Closes#19214.
This gcc version claims support for this attribute, but actually doesn't
support it and returns unclear errors when it is used, e.g.
$ echo '[[deprecated]] int x;' | g++-5 -fsyntax-only -x c++ -
<stdin>:1:1: error: expected unqualified-id before ‘[’ token
so disable its use with gcc < 6.
Add yet another wxDEPRECATED_XXX macro, this one simply expanding to
C++14 [[deprecated]] attribute if it's available and nothing otherwise.
It's a bit ridiculous to have so many different macros for deprecating
things, but the new one is useful because the standard attribute can be
used to deprecated enum elements, which is impossible with MSVC-specific
__declspec(deprecated).
This seems to work fine with current version of wxPopupTransientWindow
and wxPU_CONTAINS_CONTROLS style and allows to drastically simplify the
whole mess of preprocessor checks in wxComboCtrl code, reducing the
logic to just 2 cases: either wxUSE_POPUPWIN == 1 under any of the major
platforms and then we use wxPopupTransientWindow or wxUSE_POPUPWIN == 0
or we use some other platform and then a TLW-based fallback is used
instead.
In spite of the amount of changes, this should only modify behaviour
under MSW where wxPopupTransientWindow is used now instead of whatever
was used before.
This is not as much of a simplification as the previous two commits
because there is no simple replacement of EVT_MOUSE_EVENTS() using
Bind() and a loop over all mouse event types has to be written
explicitly, but it still avoids the need to allocate and delete a
separate object, so is still worth it.
There is no need to use a separate wxEvtHandler here when we can just
use Bind() to directly handle the child text control events in
wxComboCtrlBase itself, this code was a left over from pre-wx3 days.
No real changes, just make the code simpler and smaller (and also
marginally more efficient at run-time).
This function was always called after calling CreateTextCtrl() and
couldn't be called at any other moment, so it didn't make much sense to
have it as a separate function, just install the custom input handler
when (re)creating the text control.
This simplifies the derived classes code.
The new method is currently supported in Qt, Cocoa, MSW ports (i.e. all
major ones except for wxGTK).
Keyboard example updated with a "Repeat" column.
Closes https://github.com/wxWidgets/wxWidgets/pull/2414
