Do it for consistency with the existing GetBitmap() overload and also
because this can be useful when we need to test for the bitmap bundle
presence before using it.
Also document both the new overload and the original one, which was
mistakenly left undocumented when it was added.
This replaces 4 calls to GetBitmap() with a single one.
Note that we now use SetBitmapPressed() and SetBitmapCurrent(), which
take wxBitmapBundle, instead of deprecated SetBitmapSelected() and
SetBitmapFocus(), which do not.
We also search for the parameter node only once instead of doing it
twice in a row if it was found, so the new code is slightly more
efficient.
Update the remaining ports to take wxBitmapBundle rather than wxBitmap
as well to make their API consistent with the tier 1 ports -- even if
there is no actual support for choosing the resolution-appropriate
bitmap in them yet.
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.
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.
Add wxToolBarBase::DoSetToolBitmapSize() which does everything that
SetToolBitmapSize() used to do and make SetToolBitmapSize() itself also
remember the size passed to it in a new field, so that we could check
that we don't decrease the bitmap size below the size requested by the
application, while still being able to decrease it if necessary due to a
DPI change.
This allows SetToolBitmapSize() to continue working as before, i.e.
scale the bitmaps up if necessary without ever scaling them down, but
also allows them to resize in both directions when DPI changes.
Closes#22105.
If a window was placed on a monitor with a different DPI than the
main display call SetWindowPlacement() a second time to apply
the window size correctly.
Closes#22108.
Since VS 2015 Update 3, the C++ standard targeted by the compiler can be
detected through _MSVC_LANG. This macro is like __cplusplus, but reflects the
actual standard understood by the compiler, unlike __cplusplus which by default
is left to an ancient value for compatibility.
Closes#22099.
This will replace the wxHAS_NATIVE_OVERLAY macro, allowing the determination
to be made at runtime. Ideally this should not be necessary, but it seems the
generic implementation may not always be good enough.
Add a new build option wxUSE_WEBVIEW_EDGE_STATIC.
If it is set to 1 the WebView2 loader is static linked into the binary
and removes the runtime dependency on WebView2Loader.dll.
This method allows to exclude a top level window from screen captures.
Windows 7 or newer is required and any macOS version is supported.
Other platforms are not implemented and will return false.
The display example has been extended to demo this ability.
Closes#22066.
This function doesn't exist in the other ports and is not really needed
in this one neither, so just remove it for now.
If we really want to have it, we need to make it available everywhere.
We must keep storing the currently used bitmap in wxMSW wxMenuItem to
ensure that its HBITMAP remains valid, as keeping wxBitmapBundle is not
enough: it may not preserve the bitmap at all (if it generates it on
demand, for example), and we may also use a different bitmap from what
we get from it (e.g. we convert mask to alpha).
Replace wxBitmap with wxBitmapBundle in wxComboCtrl to make it show the
bitmap appropriate to the current DPI scaling.
Also add an event handler updating bitmaps on DPI change.
Closes#22032.
The change of 8aae7ad937 (Fatal exception fixed in DVC on macOS while
wxDataViewModel::Cleared call + editing item., 2022-01-17) broke change
of selection when deleting an item from wxDataViewCtrl and the unit test
checking for this but, somehow, only when it was merged into the latest
master and not when it was originally done.
It's not really clear how did it work before, but fix this now by
distinguishing between just deleting some items and clearing everything
and only returning nil from -[wxCocoaOutlineDataSource
outlineView:child:ofItem:] in the latter case, but not the former one.
Also replace wxDataViewCtrl::m_Deleting boolean with an (opaque)
pointer, so that we could improve this further in the future without
breaking the ABI.
See #22025.
Use a RAII-based helper class to reset this flag automatically on scope
exit instead of doing it manually.
This also ensures that we restore the original value rather than just
resetting it which would be more correct in the (admittedly, very
unlikely) case when any of the functions changing m_Deleting is called
recursively.
SetIncrement() was already available in wxSpinCtrlDouble and GTK version
of wxSpinCtrl, now implement support for it in wxMSW and wxOSX as well.
In fact, in wxMSW, implement it at wxSpinButton level, so that both this
class and wxSpinCtrl inheriting from it (in wxMSW only) support setting
custom increment now.
Also add support for it to XRC, show it in the sample and add a unit
test verifying that it works.
Closes#2597.
