This fixes compilation after the changes of 148f56085f (Define
NIIF_LARGE_ICON ourselves if it's not defined, 2022-02-19) for the
compilers using headers so old that they don't even define NIIF_USER
which exists since XP SP2 -- which includes MinGW 5.3 used for our
AppVeyor CI builds.
Instead of getting the bitmap of the default size and then possibly
rescaling it, get the icon of the correct size directly from the bitmap
bundle, which could yield better results (and at worst would do the same
thing as before, but with less code).
See #22138.
It should actually always be defined when using any of the currently
supported compilers, but define it ourselves just in case it isn't.
At least get rid of #ifdef checking for it in the code.
See #22138.
The code added to this function in ae7fa19ae3 (Improve fallback logic in
wxArtProvider::GetBitmap{,Bundle}(), 2022-01-31) didn't do anything at
all because of forgotten "break" after creating the bundle.
Also tweak this code slightly because it was not optimal: consider a
situation with 3 providers, the first one not having neither the bitmap
nor the bundle with the given ID, the second one having the bundle and
the third one having only the bitmap. With the old logic here (if it
were fixed to actually work), we would return wxBitmapBundleImplArt,
i.e. use wxArtProvider::GetBitmap() that would end up getting the bitmap
from the provider 2 bundle, i.e. do the right thing, but in a rather
indirect way.
With the new version we just return the bundle of the provider 2
directly. And we also avoid calling GetBitmap() more than once, which is
unnecessary as its return value doesn't change anyhow.
wxSizer::SetSizeHints() already does what Fit() does (while also setting
the minimum window size to the fitting size), so there is no need to
call both of them.
No real changes, just some cleanup.
These dialogs are pretty similar, so use the same wxSizerFlags arguments
when constructing them for consistency.
Using wxSizerFlags::Border() instead of hard-coded 5 or 10px is also
more correct and improves wxNumberEntryDialog appearance in high DPI
under MSW.
There is no need to call SetAutoLayout() explicitly after (or just
before) calling SetSizer() with a valid sizer pointer, as SetSizer()
already enables automatic layout, so just drop the useless calls.
No real changes.
For some reason lost in the mist of time (this seems to have started in
92afa2b150 (Did somework on the generic dialogs, Renamed wxBox ->
wxBoxSizer Removed old dialog layout code,, 1999-08-11)) we were setting
busy cursor while creating several generic dialogs.
This is completely useless, so just stop doing it.
The backing bitmap needs to be updated when the window scrolls.
This works well on MSW and GTK2, but GTK3 with X11 still has
artifacts, because GtkScrolledWindow draws onto the client area.
Add more wxNOEXCEPT to hash-related classes to avoid warnings like
.../c++/bits/hashtable_policy.h: In instantiation of ‘std::__detail::_Hashtable_ebo_helper<_Nm, _Tp, true>::_Hashtable_ebo_helper() [with int _Nm = 1; _Tp = wxStringHash]’:
include/wx/clntdata.h:33:22: recursively required from ‘std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::unordered_map() [with _Key = wxString; _Tp = int (*)(void*, void*); _Hash = wxStringHash; _Pred = wxStringEqual; _Alloc = std::allocator<std::pair<const wxString, int (*)(void*, void*)> >]’
include/wx/clntdata.h:33:22: required from here
.../c++/bits/hashtable_policy.h:1112:40: error: noexcept-expression evaluates to ‘false’ because of a call to ‘wxStringHash::wxStringHash()’ [-Werror=noexcept]
1112 | _Hashtable_ebo_helper() noexcept(noexcept(_Tp())) : _Tp() { }
| ^~~~~~~~~~~~~~~
In file included from include/wx/clntdata.h:16,
from include/wx/event.h:17,
from include/wx/evtloop.h:14,
from tests/testprec.h:5,
from tests/allheaders.cpp:410:
include/wx/hashmap.h:568:5: note: but ‘wxStringHash::wxStringHash()’ does not throw; perhaps it should be declared ‘noexcept’
568 | wxStringHash() {}
| ^~~~~~~~~~~~
that started to be given my MinGW x86-64 10.3.9 (although they were not
given by 10.2.1 version of the same compiler).
But adding wxNOEXCEPT here is more consistent with the changes of
7d74df9a03 (Add wxNOEXCEPT to the hash structs operator() declarations,
2020-08-30) and makes sense anyhow.
WM_NCCREATE is not received for dialogs, so use a different message.
There seem to be no other messages that are always and only send on
creation, so use WM_NCCALCSIZE which seems always generated but not too
often.
Use m_activeDPI to determine if the DPI variables have been initialized
or not, instead of adding another variable for this.
Closes#22133.
Don't always return success from this function, NanoSVG just skips
everything until the start of the XML prologue and doesn't return an
error even if it doesn't find it at all, so check that it could parse at
least something to avoid returning a "valid" bundle not containing
anything at all.
Add a unit test checking that we actually can't create an SVG from a
.bmp file (which is something that "worked" before).
High DPI support didn't work for wxMDIParentFrame (and everything
inside it) because it was only enabled when InheritAttributes() from
wxNonOwnedWindow was called and this was only done in wxTopLevelWindow
but not in this class.
Fix this by removing the need to call InheritAttributes() at all and
just initializing m_perMonitorDPIaware when the window is created
automatically, to ensure that it can't be forgotten.
Co-Authored-By: Maarten Bent <MaartenBent@users.noreply.github.com>
Closes#22116.
The new name, recently introduced in 94716fd801 (Add
wxBitmap::CreateWithLogicalSize(), 2022-01-22), was perhaps more clear,
but also misleading and confusing because the postcondition
CreateWithLogicalSize(size, 2).GetLogicalSize() == size
was not satisfied under MSW, so rename it once again, and hopefully
finally, because the new name is consistent with GetDIPSize() returning
the same size.
Also try to improve the documentation a bit more.
Unlike under Mac (see previous commit), this never worked correctly in
wxMSW at all, only SetScaleFactor() could be used to change the scale
factor of the bitmaps there.
Fix this and make CreateWithLogicalSize(..., scale) result in
GetScaleFactor() returning the same scale for the resulting bitmap, as
expected, under MSW too.
Also add a unit test verifying that this holds.
Optimization of 2ae80673ff (Avoid unnecessarily unsharing bitmaps in
wxMSW, 2022-02-02) broke setting the scale factor because we didn't
update the right bitmap data in case bitmap hadn't had exclusive
ownership of its data before. Fix this by not using a reference which
may refer to another object after AllocExclusive() call.
Also change the other ports to unshared the bitmap when modifying its
scale factor so that the new unit test passes for them too.
Share the same variable between GetWatchDir() and RemoveWatchDir() to
make things more clear.
Also check for GetWatchDir() postcondition (i.e. that the directory
exists) in the function itself instead of doing it in the caller.
Cast the expected number of matches to "int" to have the same type as
wxRegEx::Replace() return value -- there is no danger of truncation here
as we're never going to expect billions of matches.
