Since 1c64bd506c (Use grep instead of fgrep and egrep, 2023-05-10) EGREP
wasn't defined in CMake build any longer, so finding the correct config
script always failed.
Fix this by using "grep -E" directly instead of "$EGREP".
Avoid implicit copy constructor warnings by using
wxDECLARE_DYNAMIC_CLASS_NO_ASSIGN_DEF_COPY/wxDECLARE_NO_ASSIGN_DEF_COPY
instead of wxDECLARE_DYNAMIC_CLASS_NO_ASSIGN.
Closes#23625.
Closes#23626.
CMake's has built-in support for checking xkbcommon using FindX11 since
3.18.
But because older CMake versions are supported, add our own module that
checks if the header and library is available.
See #23410.
Closes#23613.
XPM files demonstrating the use of wxBitmapBundle in the XRC files
were not copied when building the XRC sample with CMake.
This should have been part of eaa769a (Use wxBitmapBundle in
wxBitmapComboBox XRC handler, 2022-02-09).
Closes#23612.
Fix compilation errors when wxNO_RTTI and wxUSE_UIACTIONSIMULATOR are
on, but one or more of wxUSE_COMBOBOX, wxUSE_CHOICE and wxUSE_LISTBOX
are off.
Closes#23611.
This reverts commit cd637663c8 (Add wxWindow::MSWAfterReparent() virtual
function, 2022-10-16) and removes wxListCtrl::MSWAfterReparent() added
in ff629f3853 (Fix drawing wxListCtrl since enabling double buffering by
default, 2022-10-16) which is not used any more now.
Clear the cached attributes when replacing the table they were used
with.
Add unit test checking that the attributes are not used any longer.
Closes#23607.
It seems that simply creating wxPaintDC, i.e. calling BeginPaint(),
ourselves and then letting the native control draw into it, disables
whichever optimizations are used by the control that break its drawing
with WS_EX_COMPOSITED, so always do this in our OnPaint(), even if we
don't need to draw anything ourselves.
This allows to avoid disabling WS_EX_COMPOSITED when wxListCtrl is used,
which resulted in horrible flicker before.
See #23585.
For some reason, "DarkMode_Explorer" theme started drawing vertical item
separators under Windows 11 even though it did not do this under Windows
10. These separators are unwanted, as they are not shown in the Explorer
list control that we try to emulate, and look ugly because they are
shifted by 1px compared to the separators drawn by the header control
with "ItemsView" theme, which is the only one in which the header looks
right in dark mode.
So explicitly erase everything below the last item when using dark mode
under Windows 11 to get rid of these separators.
Unfortunately drawing just the selected item ourselves and let the
control draw all the other ones doesn't work too well as the offsets
used for the items differ between Windows versions and so it's difficult
to get them right, but getting them wrong is very noticeable as when
browsing through the control the current item seems to jump because it's
shifted compared to the other ones.
So just draw all the items ourselves: this is not as nice as letting
Windows do it, but it ensures that they use consistent positions.
Fix wxSocketImpl::RecvDgram() when caller requests fewer bytes than
are present in datagram, as we must always read all the available bytes
when using UDP -- they are not buffered by the OS and so won't be
provided by the next Read() call.
Closes#23594.
Closes#23604.
This was accidentally broken by the previous changes and the C-level
locale was not set at all any more, even when using wxLocale (and not
just wxUILocale, which is not supposed to set it) under macOS.
Fix this by explicitly calling setlocale() on this platform to restore
the previous, and documented, behaviour.
Closes#23557.
See #23603.
None of the major ports need the removed code anyhow. We can always restore it
later if any of the (still) supported ports are affected by this removal.
This fixes several minor bugs in the loading of `BI_BITFIELDS` bitmaps,
related to handling different header sizes and the colour and alpha
masks.
Closes#23601.
The old API allowed for users to directly test the variable and find if
it was null, so recreate that API with the new system to preserve
compatibility.
Closes#23445.
This constant was already used in wxAuiMSWTabArt, so there are clearly
no problems with using it with the currently supported compilers/SDKs.
No real changes.
The "ExplorerStatusBar" theme used to make the rest of the status bar
appear (almost) correctly in dark mode doesn't seem to define SP_GRIPPER
at all and doesn't draw it, so handle WM_PAINT and draw the gripper
ourselves using "Status" theme, which looks fine in dark mode too.
These functions are more convenient to use and, arguably, more clear to
read than calls to ::GetThemePartSize(), so add these wrappers and
replace most of the uses of the Win32 function with them.
This shouldn't result in any real changes to behaviour.
This is sightly shorter/more convenient to use than providing all the
parameters to ::DrawThemeBackground() every time.
Similarly to ca5f244f15 (Add wxUxThemeHandle::GetColour() replacing
MSWGetThemeColour(), 2022-12-09), this is just a refactoring which
shouldn't result in any changes in behaviour.
Use OpenThemeDataForDpi() if necessary to retrieve the correct metrics
values for non-default DPI.
Change the existing wxUxThemeHandle ctor taking wxWindow to use the
window DPI automatically and replace the ctor taking HWND with a pair of
functions either explicitly specifying the DPI or indicating that it is
not used -- the latter can be useful to avoid unnecessary complications
when the theme is only used to retrieve some colour values that don't
depend on the DPI anyhow.
Also make wxUxThemeHandle class movable as a side, but possibly useful,
effect of these changes.
We need to manually adjust the background of this window as it uses
fixed background colour, which is wrong even in the default light mode
if the dialog uses a different background colour, and wrong even with
the default background in dark mode (where the gripper uses #383838
while the default dialog background is #202020).
Reuse the CustomPaint() function which was already used for drawing some
other controls in dark mode to do it.
wxPG_PROP_ACTIVE_BTN and wxPG_PROP_SHOW_FULL_FILENAME can be used together
(like e.g. in wxFileProperty) so they can't share the same value
(wxPG_PROP_CLASS_SPECIFIC_1).
Closes#23565.
For one hand this is a simplification. In the other hand, SetClippingRegion()
and SetDeviceClippingRegion() are both working the same as in the other ports.
