Fall back to old style file dialogs in this case, as IFileDialog just
doesn't seem to support this COM threading model, as hinted at in
SHBrowseForFolder() documentation.
Also document this limitation.
Closes#23578.
Use month and weekday names in standalone context form, which can be
different in the one used for formatting dates in some languages, and
which needs to be used when the month or weekday names used are used on
their own, as here.
See #23191.
Implement wxUILocale::GetMonthName() and wxUILocale::GetWeekDayName() in
wxMSW, wxGTK, and wxOSX.
Also extend the existing wxDateTime methods to support a 3rd month and
weekday name representation (Name_Shortest) and a usage context
(Context_Formatting and Context_Standalone).
These changes make wxDateTime methods for getting the localized date and
month names use the current UI locale, as set by wxUILocale, instead of
the current C locale set by the standard C library function, which is a
change in behaviour but a desired one and notably fixes the display of
the months in generic calendar control in wxOSX where the current C
locale is not changed when the UI locale is set.
Replaces #23551.
Closes#23191.
Adjust the code to check for Windows sort order only after the last
underscore (instead of the first one).
This avoids misinterpreting locale tags like "zh_Hans_CN".
For wxOSX return "C" from GetName() for "en_US_POSIX" which is now
used as the standard "C" locale.
Also handle special locales "C" and "POSIX" properly in
wxLocaleIdent::FromTag().
Replace systemLocale by locale identified by en_US_POSIX because
systemLocale doesn't provide any reasonable month and weekday names
unlike the latter and this will be important for the upcoming commit.
This macro was mentioned in the docs added by 0ff1bdec09 (Add
wxFullScreenEvent for macOS, 2021-03-18), but its implementation was not
added by said commit.
Closes#23566.
The colour used for odd rows was much too light in the dark mode and was
actually much lighter than the colour used for the selection, which is
much more important than cosmetic zebra striping.
Fix this by strongly decreasing the lightness change in dark mode, from
50% to 10%, which results in using #363636 on #202020 which is the
default dark mode background in wxMSW, instead of #8f8f8f used before
(by comparison, light mode uses #f7f7f7 on #ffffff background).
See #12834.
Switch to using "DarkMode_Explorer" theme for it in dark mode, bringing
the following improvements:
1. Scrollbars are dark now, as they should be.
2. There are no vertical separator lines in the control any more, which
is unexpected and especially jarring because they misalign (by 1px)
with the header separators.
To make "DarkMode_Explorer" work we have to take care of drawing the
selected items ourselves, as they appear completely wrongly in this
theme by default, so do take care of this by changing the custom drawing
code to use the colours appropriate for both light and dark mode and
also fix yet another misalignment problem in it by changing the offset
used for the item rectangle: it's not clear why the offset, added back
in c9a695b777 (wxMSW: Fix incorrect subitem rect calculation in
wxListCtrl., 2012-09-07) differed for the first and non-first columns,
but the first column offset is off by 2px under both Windows 10 and
Windows 7 now, which resulted in a noticeable shift of custom-drawn
items compared to the normal ones.
The focus rectangle wasn't drawn correctly due to the of ClientHDC in
the painting code, which didn't work when using compositing.
Use the provided HDC, as in the rest of the drawing code, as it seems to
work fine now and the comment saying that it didn't, written back in
2006 was either erroneous or, more likely, out of date by now.
Creating Chinese locales such as zh_TW didn't work because this string
didn't appear in [NSLocale availableLocaleIdentifiers] return value,
as only the variants explicitly specifying the script were included.
Fix this by ignoring the script part when checking if the locale is
available. This should work well for zh_TW or zh_SG, which exist only in
a single script (traditional and simplified, respectively), but it's not
really clear whether it works, or what should we do if it doesn't work,
for zh_CN or zh_HK both of which exist in both scripts.
See #23209.
In addition to showing whether the locale is supported or not, show all
of its components to allow interactively verifying if an identifier is
being parsed correctly.
Disabled static controls looked ugly as greying out the label doesn't
work at all when the background is dark, so override their drawing in
this case and just draw them using the same grey-ish colour that is
already used for the disabled menu items.
This is somewhat of a hack, but doesn't seem to have any bad effects and
is much simpler than using owner-drawn controls.
The colours have somehow got completely mixed up when they were made
customizable in 76fffafcd0 (Allow customizing menu bar menus colours in
MSW dark mode, 2023-02-19) and the menu bar looked completely wrong and
too bright as the result.
Also reuse wxSYS_COLOUR_MENU instead of duplicating its 0x2b2b2b value.
Calling Clear() wrongly modified any other wxImage objects reusing the
same data.
Fix this by adding the missing call to AllocExclusive() to this function
and also add a check for the image validity which was missing there as
well ever since this function was added back in fc3762b5fc (add
wxImage::Clear (patch by troelsk); closes#10141, 2009-01-09).
Also add a unit test.
Closes#23553.
No real changes, just don't use compatibility macros any longer.
Also remove URLTestCase as it's useless now when we can just use
wxSocketInitializer directly.
This reverts changes to one of the arrays in 39706e4db0 (Use wxBaseArray
instead of object arrays in wxAuiManager, 2023-04-11) as this array is
returned by wxAuiManager::GetPane() and the existing code relies on the
references to the elements of this array remaining stable even if the
array is modified, which would be impossible with an array storing the
objects directly, so return to storing heap-allocated pointers to it.
There should be no such problems with the other arrays changed by that
commit, so leave them unchanged.
Closes#23545.
The wxThreadSpecificInfo object created by wxThreadSpecificInfo::Get()
was only released by the wxThreadInternal's cleanup, which meant that it
was leaked if wxThreadSpecificInfo::Get() was called by a thread not
created by wxThread, e.g. when using std::async or std::thread.
Fix this by simply using C++11 thread_local and removing the entire
wxThreadSpecificInfo machinery entirely.
See #23535.
Closes#23543.
This doesn't work due to LM_GETITEM not returning the expected result
after changing the state using LM_SETITEM under Wine.
It could be worked around by remembering whether we changed the colours
in our own variable, or maybe just reverted later if Wine fixes this,
but for now disable the test.
The default blue doesn't have enough with the typical dark mode
background, so use a much lighter shade of blue in this case.
The choice of the exact colour to use is pretty arbitrary, but there
doesn't seem any standard value for the link colour in the dark mode.
This isn't supported by the native control, and it doesn't seem worth to
make an extra effort to support it, so just document it and stop
checking that it works in the unit test.
Set LIS_DEFAULTCOLORS to allow the already existing code calling
SetForegroundColour() in wxGenericHyperlinkCtrl to work.
Changing the foreground colour has an unfortunate side effect of also
changing the colour of the focus rectangle, but it doesn't seem possible
to avoid this.
Include the header declaring the stream insertion operators for these
types before including catch.hpp itself as otherwise they may not be
seen when these classes are used and Catch::StringMaker is instantiated
using the "unstreamable" alternative for them.
It would probably be better to specialize Catch::StringMaker for these
types directly instead of relying on stream insertion operators, but
this would require more changes and in the meanwhile this improves the
display of failing checks.
Return the correct foreground colour from this function for hyper links,
it's different from the default text colour for the links.
This makes it easy to reuse this colour for the link-like elements in
the application code.
Add an overview paragraph explaining how to use wxWebRequest's and
wxWebEvent's IDs together to specify a request's download path before
starting it. The sample shows how to interactively prompt for local
paths once a file downloads, but not how to download a file to a
specific location without user prompting, so document how to do it.
See #22986.
Closes#23504.
Get the colour actually used by the theme part we use for the status bar
in the dark mode, which is quite different from the default background
colour (0x333333 vs 0x202020).
This is notably important for the controls that live inside status bar
panes, as they must use the correct background colour to blend in.
This function returned wrong results when using a non-default font in
non-standard DPI because it didn't adjust the font to use the window
DPI, as needs to be done manually in wxMSW before using it.
Fix this now and do the same thing here as we already did in
wxWindow::SetFont() (via WXAdjustFontToOwnPPI()) or in wxDC::SetFont().
