It's not clear whether we handle them correctly, and so it might be
better to refuse input with duplicated groups entirely, but for now at
least avoid asserting when encountering them.
Add fields for the information about the distribution this one is based
on to wxLinuxDistributionInfo and add them wxGetOsDescription() if
available/applicable.
Closes#26641.
Don't try allocating arbitrarily large amounts of memory for the
extended header in wxTarInputStream and impose a very big but still
reasonable enough to not result in out of memory condition size for it
by default.
Allow changing this size via the newly added SetMaxExtendedHeaderSize()
function for the applications that want to handle files with even bigger
header or, on the contrary, want to avoid allocating even that much.
This should fix running out of memory in OSS-Fuzz runs using the fuzzer
for this class.
Closes#26588.
Closes#26607.
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
On Windows in dark mode, explicitly draw borders rather than relying on
DrawThemeBackground(), which does not work well on older versions of
Windows.
Closes#26646.
Fix dark mode border flicker by using a clipping region when calling
MSWDefWindowProc(). This prevents drawing the light mode border before
the dark border is drawn.
See #26646.
This reverts commit 75284bb8f0 because it
doesn't always use the right window: at least under Windows 11 25H2 it
is possible that the center of the window is still on the old display
when we receive WM_DPICHANGED and so the window is moved to a wrong
position because of the check added in that commit.
Because this check was mostly needed to work around other issues that
made the window become too big, it seems better to revert it rather than
break something that worked correctly before.
See #26604.
This was done manually in 9864777203 (Upgrade to Doxygen 1.15.0,
2026-05-05) but the changes were lost after regeneration, so add an
override for this function documentation to the generating script itself
to ensure that they're preserved.
This also has the nice side effect of generating a better comment in the
header.
See #26431.
Remove the background colour setting from wxVListBox::Create() so that
the control uses the up-to-date background colour in the paint event
handler. This way the control responds to system colour changes.
The comment about transparent drawing is wrong since 0975a8a (Applied
patch [ 1405821 ] wxVListBox double-buffering + fix to a scrolling issue
By Jaakko Salli, 2006-01-17).
Closes#26636.
Move colour settings from Create() into a new function UpdateColours(),
which gets called from Create() and also upon system colour change.
Closes#26633.
Add dark mode support to wxFontPreviewer:
- Replace manually drawn black-on-white border with window border
wxBORDER_SIMPLE.
- Set text colour to wxSYS_COLOUR_WINDOWTEXT.
Closes#26632.
For dark mode switching, update the background colour for non-rich
read-only multiline wxTextCtrl controls. The foreground colour is
already updated.
The background colour is controlled by assigning m_backgroundColour
rather than calling SetBackgroundColour(). This leaves the m_hasBgCol
member untouched so that it distinguishes custom colours set by the user
which should not be overwritten, from colours set internally which can
be overwritten.
Some checks of hasBgCol are changed to m_backgroundColour.IsOK(). When
m_backgroundColour.IsOK() is true, there is either a custom colour or an
internally set colour that we need to use.
Closes#26629.
Under KDE, the ribbon takes a blue hue because its system gray has a
blue tint in it that gets amplified here. This balances this to look
more like how dark mode is under macOS and MSW.
Closes#26627.
This ensures that they are always initialized, even when the default
ctor is used, which wasn't the case before for m_help_button_hovered
which was never set in this case, resulting in UBSAN errors when running
the ribbon sample.
wxIPCSocketStreams::ReadData() reads a length prefix from the connection
and then reads that many bytes into the buffer returned by
GetBufferAtLeast, but it never checks how many bytes actually arrived.
That buffer is either freshly allocated and so uninitialised or, more
commonly, the connection's own buffer reused from an earlier and
possibly larger message, so a peer that announces more data than it
sends and then drops the link leaves the unread tail untouched and it
gets handed to OnExecute/OnPoke/OnAdvise with the full announced size,
quietly leaking stale process memory across the connection. The socket
reads are done in WAITALL mode so a short read only happens when the
peer is broken or hostile, and every caller already treats a null return
from ReadData as an error, so the safe thing is to return nullptr when
fewer bytes than announced were read instead of using the partially
filled buffer.
Closes#26628.
Use fitting window size, not client size, which was wrongly used in
8386a98409 (Restrict the new size after DPI change to the display size,
2026-06-16).
See #26604.
Instead of ignoring the user-set background colour and always using the
system default colour in the hot (a.k.a. current) state, use a slightly
different shade of the custom colour.
This avoids, or at least reduces, problems with the button text becoming
unreadable on the default background but still makes the button change
its visual appearance when the mouse hovers over it.
See #22721, #25806, #26453.
These accessors for the frozen row and column label sub-windows were
missing from the public API even though the equivalent data cell windows
(GetFrozenRowGridWindow/GetFrozenColGridWindow) are already public.
Without them it is impossible to bind events (e.g. EVT_MOTION) to the
frozen label strips from outside the wxGrid implementation.
Closes#26617.
Using the wxDC origin to implement scrolled drawing can require very large
origin offsets, which can exceed Cairo coordinate limits (2^23), and therefore
currently wxGTK3 limits as well. Managing the scroll offsets turns out to be
pretty simple in this case, avoiding any coordinate limitations.
See #25365
This reverts commit f3ab568a02 because
people do want to use the selected foreground colour even in "current"
state, see #26453.
A better solution will be implemented for the problem of #22721 which
was originally solved by this commit, see #25806.