The documentation used to warn that wxXXX_BOX styles were ignored unless
wxCAPTION was also specified, but this was actually wrong, at least for
wxOSX, which instead enabled wxCAPTION too if any of the BOX flags was
given.
And this behaviour seems more useful, as it's not really obvious why the
boxes are not shown otherwise, so make wxMSW behave like this too and
update the documentation.
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.
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().
Account for the special case of partly visible rectangle whose center is
off screen, as in this case GetFromRect() would still be expected to
return a valid display and not wxNOT_FOUND.
Also mention this case in the documentation.
It was unexpected that changing the window client size could change the
display the window was on and, even worse, result in further size
changes because changing the display could change the DPI scaling used.
And, worst of all, if the window wxEVT_DPI_CHANGED handler called
SetClientSize(), possibly indirectly such as via wxSizer::Fit(), this
could result in an infinite recursion when moving the window to a high
definition display located to the left of the standard definition one
(the problem didn't happen for the reciprocal display arrangement
because increasing the window size couldn't change the window display
in that case).
So ensure that the window remains on the same display it is on now, by
keeping its center position unchanged, instead of keeping the position
of its top left corner as we did before.
For now this is just the same thing as GetFromPoint(center-of-rectangle)
but it's already more convenient to use and it will also be changed in
the upcoming commits.
