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).
This was done back in 0cd159592e (save the current status text for each
pane inside wxStatusBarPane [...], 2009-02-09), but without any real
explanation about why is it needed and doesn't seem useful. Besides,
doing this requires updating this DC in several places, so just don't do
it and create the DC only when we need it.
Use a vector of unique_ptr<> to manage memory automatically instead.
No real changes, this just simplifies the code and makes it more robust
by making it impossible to forget to delete a tooltip.
There doesn't seem to be any reason to have it in GetSize() and
GetDimension(), where they were added by 0c00c86faf (fixed dialog units
in toplevel windows (bug #1170234), 2005-03-28), but not in this
function, so add it here as well.
Set DPI to 96 in RenderTargetProperties when creating HwndRenderTarget
to prevent pixel scaling.
If the value is set to zero, Direct2D sets the HwndRenderTarget's DPI to
match the window's DPI.
When the DPI of the ID2D1RenderTarget is not set to 96, Direct2D
performs pixel scaling.
See #23486.
Closes#23496.
Some compilers, including gcc 7, don't provide <charconv> even though
they do (partially) support C++17, so check for the header existence
explicitly, using __has_include (which is, ironically, another C++17
feature) to avoid compilation errors when using them since the changes
of 65c048568f (Use C++17 <charconv> for wxString to/from number
conversion, 2023-04-05).
Closes#23484.
Closes#23487.
Clarify when each of the overloads is available and also document that
std::istream must not be in failed state for LoadObject() to be
considered successful.
Closes#23479.
Clarify that it is 1 by default in the documentation, instead of
implying that it's off by default and needs to be enabled.
Improve the description of this option in setup.h files.
And also document this compilation option in the summary page.
The old comment was misleading, mention that we need this header not
just for <windows.h> inclusion (which could be achieved by just
including wx/msw/wrapwin.h), but for wxMSWFormatMessage() declaration.
No real changes.
