This reverts most of the changes from ee2b02614e (Add GetDPIScaleFactor to wxDC
and wxGraphicsContext, 2022-04-16).
This is not supposed to be used to scale pixels, FromDIP will be added instead.
Temporary use scale=1 in the drawing sample until FromDIP is added.
MSWDefWindowProc(WM_PAINT, ...) in OnPaint causes performance issues on
large screens so only use it when an actual custom background colour is
set.
Closes#22308.
Closes#22320.
It can be used to scale coordinates and sizes to make them DPI aware.
In the common headers, use wxDisplay::GetStdPPIValue() as default DPI value,
so the correct values are used on Windows (96) and macOS (72).
In wxMemoryDC use m_contentScaleFactor as the DPIScaleFactor, see e4c2298e5e
(Use window scale factor for all MSW wxDCs associated with windows, 2022-04-04).
No real changes, just don't redeclare the classes already forward
declared in wx/bitmap.h in the files included (only) from it and don't
include redundant headers.
Also forward declare wxCursor and wxPixelDataBase in wx/bitmap.h itself
for consistency, as many (even though not all) headers use them.
Do not forward declare wxControl in wx/{msw,osx}/bitmap.h, however,
there is no reason to do it in this header.
This ensures that we use correct font sizes with the DCs and, in
particular, fixes the font size in wxAutoBufferedPaintDC when using DPI
scaling different from 100% after the changes of e3557b8c0a (Respect
bitmap content scale factor in wxMSW wxMemoryDC, 2022-03-26).
See #22234.
Apply it manually because MSW doesn't do it automatically for us and
also adjust the font size in wxMemoryDC as the base class version only
does it for the device contexts associated with a window, but we also
need to do it when using a wxMemoryDC for a bitmap using scale factor
different from that of the main display.
As the result of these changes, contents drawn on wxMemoryDC, both
directly via its own methods, or via wxGraphicsContext (using either
GDI+ or Direct2D) created from it, it appears the same as in wxWindowDC
(e.g. wxPaintDC) created for a window using the same scale.
Closes#22130.
Closes#22234.
It is possible to use WindowHDC as ScreenHDC by passing a NULL HWND to
its ctor and we still need to release the HDC allocated in this case in
the dtor, so do _not_ check for HWND being valid there.
This fixes a bad resource leak in wxWindow::GetDPI() when it's called
for a window without a valid handle.
Closes#22193.
Closes#22194.
This reverts commit de10f054c4 and a bunch
of commits improving it done since then:
6f888df474 (Restore button size calculation when not using manifest in wxMSW, 2021-04-24)
de10f054c4 (Improve calculating wxButton best size under wxMSW, 2021-04-08)
6f888df474 (Restore button size calculation when not using manifest in wxMSW, 2021-04-24)
75d508b6e6 (Fix regression in sizes of buttons with bitmaps in wxMSW, 2021-07-08)
051418ac00 (Fix recent wxMSW buttons with bitmaps appearance regression, 2021-08-26)
fbc6462375 (Fix a gcc warning introduced by the previous commit, 2021-08-26)
The reason for reverting is that using BCM_GETIDEALSIZE doesn't seem to
have any advantages compared to using our old code, as it doesn't take
the margins into account neither and we still have to add them ourselves
and so it's simpler to just always do it without using this message.
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.
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.
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).
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.
The previous implementation initialized the version number only once.
This caused subsequent calls to wxWebView::GetBackendVersionInfo() to
return the same version number even if the runtime has been updated or
a fixed version runtime had been activated via
wxWebViewEdge::MSWSetBrowserExecutableDir().
This change allows to require a minimum runtime version and allow
a runtime update without requiring a restart of the application.
Closes#22076.
When SetPage() was called during the webview was still initializing
it would silently fail. This will now load the contents when the
webview is ready. Additionally error handling for the underlying
NavigateToString() has been added so it wont fail silently.
Closes#22052.
This makes them available in wxIcon (and, less importantly, wxCursor)
too which is needed in order to use icons correctly in high DPI.
This is also more consistent with the other platforms, where wxIcon does
have these methods.
Document these methods in wxIcon now that they're available there under
all platforms and also document wxIcon::GetSize() which had been
available even before, but wasn't documented.
The new function has a more clear name than CreateScaled() it replaces
and uses a more useful parameter order, with the scale factor, which
must always be specified when using it, coming before, and not after,
the depth, which almost never needs to be specified and so can be left
at its default value in 99% of cases.
These functions have better names than the existing GetScaledXXX() ones,
so add them to be able to use them in the new code, even if we still
keep the old ones for compatibility.
This fixes the problem with wrong standard bitmaps size when using high
DPI for the main monitor with wxMSW, as GetScaledSize() used here since
31f2892200 (Avoid bitmap scaling in wxArtProvider::GetBitmapBundle(),
2021-12-17) was not the right function to use there.
Closes#19331.
wxBitmap::GetScaledXXX() functions are useful for obtaining the
coordinates in logical pixels, so they should only divide by the scaling
factor on the platforms where logical pixels are actually different from
the physical ones, i.e. those using DPI-independent pixels.
This ensures that their behaviour under MSW remains unchanged even after
a1e4dca067 (Store scale factor in wxMSW bitmaps too, 2021-12-16), which
is the correct way to avoid breaking wxAUI (and other) drawing.
This undoes the part of 77d8926126 (Simplify Windows application
manifests, 2021-12-17) which removed special handling of MSVC from
wx.rc, as it's still needed.
In section "dependency" use "*" in processorArchitecture instead of specifying
the concrete architecture such as "amd64" or "x86". This allows to have just one
manifest for all architectures instead of having them for all supported architectures
individually differing in just processorArchitecture.
