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.
wxRibbonButtonBar::GetItemRect() and wxRibbonToolBar::GetActiveTool()
are helpful for positioning other windows (e.g. popup ones) that should
be aligned to tools and buttons in the ribbon bar.
Closes#22329.
Ensure that the font has exactly the point size entered in the dialog,
rather than having a fractional point size close, but not identical, to
it, as happened before due to first rounding the result of converting
the point size to pixels and then _not_ rounding the result of the
reverse conversion.
This resulted in wxFont::GetPointSize() returning the correct value, but
not GetFractionalPointSize(). Now the latter returns the same, correctly
rounded, value too.
The native dialog doesn't take the actual DPI into account, so convert
our font sizes that do use the DPI to the standard one before using it
and convert font height back to the value corresponding to the actual
DPI once a font is selected in it.
Closes#22313.
Restore the old behaviour of wxLocale, which is supposed to use the
default locale and not the preferred language, which may not be the same
(see #22281).
Also apply the following fixes and improvements to wxUILocale:
- Add new GetSystemLocale() method.
- Change the MSW implementation to use the default locale instead of the
preferred UI language for Windows versions below Windows 10.
- Change the Unix implementation to respect LANGUAGE environment
variable and use it for determining the preferred UI languages.
- Use wxUILocale in wxTranslations to determine the preferred UI
languages.
- Use wxUILocale during initialization of internat sample.
Closes#22281.
Closes#22318.
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.
Don't just wxASSERT(err == 0), as this expands to nothing in the release
builds. Use wxCHECK() instead so that we at least return an error even
in the release builds too.
Avoid manual memory management.
This was already fixed once in 563f41c686 (Fix memory leak on error
return in wxOSX wxDisplay code., 2014-02-21) but incompletely and then
another instance of new/delete[] was reintroduced in d5180d3604 (add a
GetFromWindow implementation to wxDisplayFactory, 2020-08-07). Get rid
of all of them now and use wxScopedArray<> instead (we could also use
wxVector<> or even std::vector<> too).
No real changes.
Make this function virtual in the base class so that it could be
overridden to do the right thing in wxAuiNotebook, instead of just
always returning NULL as before and add a unit test checking that it
works.
Explain that wxBookCtrlBase::m_pages may not be used in the derived
classes, but that in this case they must override all the methods using
it.
Finally, "soft-deprecate" wxAuiNotebook::GetPageIndex(), which is
identical to FindPage() now.
This fixes infinite recursion when handling wxEVT_HELP in wxAuiNotebook
in wxUniv too, see #22309.
Closes#15932.
Restrict the extra workaround for wxUniversal wxNotebook added back in
ec09e18d35 (more fixes to OnHelp() to avoid infinite recursion when
handling help events, 2006-06-14) to wxUniversal, to keep the code
simpler and more robust in the main ports.
Notably, this is sufficient to fix infinite recursion when pressing F1
in a wxTextCtrl used as a wxAuiNotebook page in non-wxUniv builds.
See #22309.
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).
This is at best useless and at worst harmful, as shown by the bug fixed
in the previous commit, so just don't do it if GetLongPathName() has
already determined that the path doesn't exist.
After the fixes to UNC paths handling, Normalize(wxPATH_NORM_LONG)
started adding an extra colon after the UNC paths.
Fix this by using wxGetVolumeString() instead of constructing this thing
manually and add a unit test checking for this.
Closes#22275.
Fix declaration of 'o' hides previous local declaration warnings.
Change two wxCONSTRUCTOR_5 definitions using wxBitmapBundle instead of
wxBitmap (this does not give build errors).
wxGenericCalendarCtrl is missing all XTI implementations, so just use
RTTI. And fix building the xti sample.
Note the shared build still fails due to WXDLLIMPEXP related issues.
Closes#22300.
Closes#22301.
Don't test for __WXMAC__ after testing for __UNIX__ just above, as the
latter is now always defined when the latter is, we don't support
non-Unix Mac systems since an awfully long time.
No real changes.
Use wxChar in wxUILocaleImplLCID to allow the code to compile and work
correctly even when GetLocaleInfo() is GetLocaleInfoA() and not the W
version as usual.
Closes#22299.
This ctor was previously present only in wxMSW, make it available in all
ports to allow the same code to compile everywhere.
In most of them wxDC argument is simply ignored, but in wxGTK and wxOSX
it is used to assign the appropriate scale factor for the new bitmap.
Enable previously wxMSW-only unit test checking for this.
This is similar to db6d565fad (Handle wxDC scale factor in wxBitmap ctor
taking wxDC in wxMSW, 2022-04-10), but for the constructor taking
wxImage and wxDC -- it should also use the DC scale factor, even if it
is not used for scaling the bitmap size in this case.
Add a unit test checking for this.
This is similar to 7382e99bbb (Create bitmaps even when given a wxDC
without an HDC in wxMSW, 2022-04-10) and does the same change to
wxBitmap ctor from wxImage and wxDC -- and also extends the unit test to
check for this under wxMSW, which is the only port in which this ctor is
currently available.
When using wxBitmap ctor taking wxDC, the bitmap should inherit the
scale factor of the DC, both because it's already the case in the other
ports and because it makes sense to do it.
Add a unit test checking that this is the case in all ports now.
It seems wrong to just fail to create the bitmap entirely if a not
wxMSWDCImpl-derived wxDC is provided to wxBitmap::Create(size, wxDC)
overload, especially because no check is done to see if the associated
HDC is non-null for wxMSWDCImpl-derived classes.
Instead, simply create a DIB-based bitmap with the specified size, as
this seems more useful and less surprising and was already the behaviour
in the other ports.
Add a test ensuring that this remains the case in the future.
Previously this ctor was only available in wxMSW and wxOSX, which was
especially strange as the equivalent Create() overload, taking wxDC, was
already available in all ports.
