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.
Don't delete the art provider object in Remove() as this contradicted
its contract and do restore the call to Remove() from wxArtProvider dtor
as it's actually documented to work.
This fixes a regression due to the changes of 4a294caacd (Stop using
macro-based wxList in wxArtProvider code, 2023-04-11).
Closes#23513.
Closes#23529.
This partially undoes the changes of bc23b1f4f0 (Use wxBaseArray instead
of object array for wxAuiToolBarItemArray, 2023-04-11) as they broke the
existing code using wxAuiToolBar because the pointers to the tools were
not stable any more.
At least avoid the use of the ugly -WX_DECLARE_USER_EXPORTED_OBJARRAY()
macro by just using wxBaseObjectArray<> directly, which is simpler now,
after the change in the parent commit.
Add a trivial test checking that pointers to wxAuiToolBar tools remain
stable when more tools are added.
Closes#23514.
This key produces events with different key codes in wxMSW (WXK_CLEAR)
and the other ports (WXK_NUMPAD_BEGIN), so add a new constant to allow
to refer to it under the same name everywhere.
Also generate a key event for it in wxOSX where it previously wasn't
generated at all.
Closes#23478.
Closes#23491.
Show the expected assert about calling wxFindNextFile() without
(successfully) calling wxFindFirstFile() first instead of not triggering
this assert if the last call to wxFindFirstFile() failed but a preceding
one had succeeded and triggering another, less clear, assert in wxDir
instead, complaining about using a not-opened directory.
Do this by only setting gs_dir to a valid value if wxFindFirstFile()
succeeded and resetting it to empty pointer if it didn't.
Calling wxXmlResource::Load() with a file using an inexistent path
resulted in an assert in wxFindNextFile() because it was called when the
preceding call to wxFindFirstFile() failed.
Avoid this by simply not calling it in this case.
Do not hide cells without values at GTK level, as this makes them not
only appear as blank (which is fine), but also prevents them from being
edited, which is not, as the user should be able to enter values into
the previously empty cells.
This fixes regression introduced back in 74e1c444fa (Don't show bogus
value when there are none in wxGTK wxDVC neither, 2021-12-01).
Note that this also undoes the changes of 8aefedcb45 (Remove duplicated
HasValue() call from wxGTK wxDataViewCtrl code, 2022-05-08) and
HasValue() is called twice again now, but this is less of a problem than
wrong behaviour fixed by this commit and we can address it later, e.g.
by passing the cell value to PrepareForItem() instead of retrieving it
inside it, if it turns out to be really worth it.
Closes#23523.
