Use system colors for generic calendar header instead of blue and gray.
A separator line is drawn below the header. This makes the control look
consistent with the Win32 and WinUI 3 controls. Custom header colors are
not overwritten by system color change event.
See #25552.
Closes#26777.
Assign values for wxSYS_COLOUR_3DLIGHT and wxSYS_COLOUR_BTNHIGHLIGHT
consistent with Linux and macOS.
Also stop using wxSYS_COLOUR_BTNHIGHLIGHT for rendering disabled text in
wxGrid and wxGenericStaticText: it didn't look before and would be even
worse after this change. Instead, just draw the text in "disabled"
colour, without using drop shadow at all.
Closes#26753.
The MFC sample unconditionally defines "_AFXDLL", which means linking
the MFC dynamically. However, this is incompatible with static CRT
linking.
Therefore, do not generate the MFC sample project when building
wxWidgets with CMake and linking the CRT statically, since the build
would have failed.
Closes#26770.
wxMenu::GtkAppend() decided between GtkImageMenuItem and plain
GtkMenuItem based on mitem->GetBitmap().IsOk() at Append() time. This
breaks the common and explicitly supported idiom
menu->Append(id, label)->SetBitmap(bmp), where the bitmap is only
attached after Append() has already built the underlying widget: for
any non-stock id, GtkAppend() picked a plain GtkMenuItem, and the
later SetupBitmaps() call (from wxWindowGTK::DoPopupMenu(), triggered
whenever the menu is actually popped up) called
gtk_image_menu_item_set_image() on it, tripping the
GTK_IS_IMAGE_MENU_ITEM assertion and silently failing to attach the
bitmap.
Always build a GtkImageMenuItem for wxITEM_NORMAL (unless a stock
GTK id already provides one). An empty GtkImageMenuItem behaves
identically to a plain GtkMenuItem, so this has no effect on items
that never get a bitmap.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CacheReadString() took the length of a string straight from the .cached
file and passed len - 1 to wxCharBuffer. A stored length of 0 underflowed
to SIZE_MAX, so wxCharTypeBuffer allocated (SIZE_MAX + 1) bytes, i.e.
none, and then wrote its terminator at str[SIZE_MAX], which wraps on
64-bit to a write one byte in front of the block. The buffer was also a
byte shorter than the read that filled it, so the terminator was
overwritten and the wxString constructor went looking for one past the
end, and a large or negative length asked for a huge allocation or a read
through a null pointer.
Size the buffer as len so the terminator survives the read, as
ReadString() in zipstrm.cpp already does, reject a length that cannot
have come from CacheWriteString() or that exceeds the file, check the
read actually delivered the bytes, and build the string from the known
length rather than by scanning for a NUL.
The contents and index counts are used to reserve memory before anything
is read, so bound them against the file as well, and move the contents
loop to std::make_unique so the new early returns cannot leak, as the
index loop already does.
Fixes#26765.
Closes#26766.
ReadTGA() sized both the image and its scratch buffer from the header's
width, height and bpp without comparing them against the input stream,
and never checked how much data the bulk reads actually returned. A
22 byte file declaring a 31232x16382 image at 24bpp therefore allocated
1.5 GB twice over, and, because a short read went undetected, LoadFile()
returned true and handed back an image of the declared size that the
file never contained.
Reject dimensions whose claimed image size cannot fit the stream before
allocating anything: uncompressed types must fit exactly, while the RLE
variants are allowed up to 128:1 expansion, since each packet costs
1 + pixelSize input bytes and yields at most 128 * pixelSize output
bytes. Also check LastRead() after the header read and after each of the
three uncompressed bulk reads, so that a truncated file is reported as a
failure instead of a success, as imagpcx.cpp has done since #26624;
DecodeRLE() already validated its own reads.
Fixes#26760.
Closes#26761.
Add missing semicolons which resulted in 2 declarations being merged
into a single one in the generated HTML.
Fix user-defined operator declaration syntax.
Fixes#26754.
Closes#26764.
Don't use the old Ubuntu version, Ubuntu PPAs are simply too flaky to be
used.
Use the latest available Ubuntu image (26.04) for all builds except
wxDFB as libdirectfb-dev package is not available in this Ubuntu version
any longer, so use 24.04 for this job.
Remove special handling of Ubuntu 18.04 which is not needed any more.
Comparison doesn't seem to use locale-specific rules by default there,
so limit the changes of 09c22b080e (Fix listboxtest test failing under
wxQt, 2023-10-08) to Windows and check for the actually observed order
under Unix.
Closes#26759.
This avoids gcc -Wsuggest-override for it.
Always define GetXVisualInfo() in wxGTK wxApp, even for GTK 3, to ensure
that this virtual function can be overridden in wxGLApp: this is simpler
than overriding it only conditionally there.
For wxTextCtrl, draw a themed border consistent with how the control
looks in light mode, and consistent with the WinUI 3 TextBox control in
dark mode. A blue line appears at the bottom when the control has the
focus.
Closes#26745.
Replacing wxIMPLEMENT_APP() with wxIMPLEMENT_APP_CONSOLE() allows
building the sample on Windows with CMake with wxWidgets built in
the monolithic configuration.
The archive sample is a console, not GUI, sample and console applications
should use wxIMPLEMENT_APP_CONSOLE() instead of wxIMPLEMENT_APP(). This
matters on Windows when compiling with MSVC and the linker subsystem set
to console.
It can still work when wxUSE_GUI=0 is defined but this is not possible
with wxWidgets monolithic build, where wxUSE_GUI=1 is defined for all
the projects.
Closes#26755.
Extract existing code solving the same problem from wxListCtrl code into
a reusable wxMSWImpl::PaintScrollBarCorner() function and use it in
wxTreeCtrl too.
Fixes#26737.
Closes#26743.
Prevent the signed/unsigned comparison compiler warning.
Remove the unused header.
Make the sample follow the wxWidgets coding style standards.
Fix the stylus sample in MSVS samples solutions.
Closes#26746.
This was dangerous because it allowed the code accidentally
dereferencing wxColour to silently compile -- and do a completely wrong
thing.
Just add a function returning GdkRGBA explicitly and use it.
See #26751.
GitHub automatically computes and shows SHA-256 checksums on the
download page, making verifying them more convenient than SHA-1 ones.
SHA-1 is also generally considered insecure nowadays.
See #26744.
This avoids the chronic problem of wxSysColourChangedEvent handlers
inadvertently failing to call Skip() and thus blocking important internal
processing, including propagating to child windows.
Also update the coefficient in wxGetSRGB() to use the correct value,
quoting the linked document:
Note 2
Before May 2021 the value of 0.04045 in the definition was
different (0.03928). It was taken from an older version of the
specification and has been updated. It has no practical effect
on the calculations in the context of these guidelines.
Don't duplicate the same code using different names in wxAUI and
wxRibbon, put it in a header which can be included from both.
No real changes, this is a pure refactoring.
Update the MSW-related parts after d7d94f9 (Support explicit
switching both to and from dark mode in wxMSW, 2026-07-24).
Closes#26739.
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
The check for whether these buttons are needed incorrectly compared the
width required by tabs with the total rectangle width, but it needs to
compare it with the width actually available for the tabs, which can be
smaller if other buttons are shown.
Closes#26738.
Fix wxChoice drop-down list scroll bar when switching to light mode by
using "DarkMode_DarkTheme" only for dark mode. Use "Explorer" for light
mode.
Closes#26736.
It was int because the initial plan was to add other flags that could be
combined with the existing ones, but now that there are 3 possible
values combining the elements of this enum doesn't really make sense any
more.
With these changes, wxApp::SetAppearance() and
wxApp::MSWEnableDarkMode() can change the dark/light mode at any time.
They can be called before or after windows are created, and can be
called more than once.
The widgets sample has new menu commands to demonstrate this.
Closes#26734.
All attempts to make it pass reliably failed, the changes of 95a47a88a9
(Make Window::Refresh test more robust under Mac, 2026-07-23) fixed it
in one Mac workflow but somehow not the other.
Just disable it to let the test suite pass again.
See #26726, #26674.
This change essentially reverts ffeeb612cd (Remove not needed code for
dark mode support under Windows 1809, 2026-06-26). The value of
DWMWA_USE_IMMERSIVE_DARK_MODE changed in Windows 10 v2004, but we
support dark mode on v1903 and later and we still need to use the old
attribute value in this version and v1909.
Closes#26732.
Steve Cornett
Vadim Zeitlin
Paul Cornett
Yannick Duchêne
PB
ykneandClaude Sonnet 5
Maarten Bent
Andy Vandijck
MarkLee131
alilie
Daniel
anhnong90
Scott Talbert
Blake-Madden
Carlo Bramini