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.
Don't hang forever in this case but just return an error immediately.
This notably fixes hanging in wxFTP::GetFilesList() as the socket it
used for retrieving the list of files was always closed by the server
after sending the full list, but we kept trying reading from it.
Closes#23519.
This changes of 4713301cf5 (Fix font and thumb size of wxSlider after
DPI change, 2019-08-27) fixed updating the slider thumb length on DPI
change, but this happened too late because it was done after executing
the user-defined handler for this event which could have updated the
slider size, which led to a call to its overridden DoMoveWindow() which
would use the old thumb length, resulting in the size remaining too big
when switching from higher to lower DPI and, worse, too small (and not
showing the thumb entirely) when switching in the other direction.
Fix this by updating the thumb length earlier, by using the just added
MSWBeforeDPIChangedEvent() for doing it instead of doing it in the event
handler.
This is unusual, but this function may need to rescale some coordinates
and it's convenient to just call event.Scale() then.
So pass it the event that we are preparing to process to it instead of
passing it new and old DPI separately and forcing it to deal with them
itself (instead of using Scale()).
This didn't work correctly when switching from higher to lower DPI if
the frame had a status bar because this status bar still had its old,
bigger height, by the time SetClientSize() was called from the event
handler, resulting in the frame size becoming too big.
It notably resulted in having an unwanted gap between the frame contents
and the status bar if the event handler called GetSizer()->Fit().
Fix this by calling PositionStatusBar(), which also updates the status
bar height to correspond to the new DPI as a side effect, from a new
virtual MSWBeforeDPIChangedEvent() function which had to be added to
allow wxFrame to customize DPI handling.
Adding this new virtual function just for this isn't great, but the only
alternatives seem even worse.
Just fix a misleading comment using the wrong (old) file name.
This should have been done in cacfcb1e61 (Allow ignoring revisions when
viewing blame on GitHub, 2022-03-24).
