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.
Using wxHAS_ prefix is more consistent with all the other similar
symbols, using wxHAVE_ was a mistake, that we have to pay for by
preserving the old name now (as it is actually already used in some code
outside of the library).
The fact that it's used also shows that it's better to document this
symbol, even if just to explain that it normally shouldn't be used, as
we can't really hide it anyhow.
Instead of immediately constructing the bitmap with the requested size,
possibly by downscaling a higher-resolution bitmap, and then potentially
having to upscale it if we actually need a bitmap of a bigger size, just
retrieve the bitmap in the actually needed size from wxArtProvider when
needed.
This makes bitmaps obtained from wxArtProvider::GetBitmapBundle() look
good, rather than fuzzy and ugly, in high DPI if they're actually
available in the appropriate size.
With scaled bitmaps, the preferred bitmap version might be too big for
the pane.
Perhaps it's the title bar height which is too small, but it seems to
have been hardcoded to 17 pixels since the very first version in
50acee04cd (Initial commit of wxAUI, 2006-06-06), so don't change it.
8dcedf56d7 (Add wxWindow parameter to wxAuiTabArt::SetSizingInfo(),
2021-11-13) added "wnd" argument to SetSizingInfo(), so use it instead
of always using the DPI of the main monitor.
::LoadIcon() selects the icon of scaled size in the DPI-aware programs,
which is nice, but only works right if we actually set the scale factor
for the icon correctly.
Even though it's not really used by MSW code itself, the scale factor is
still needed to determine the correct default bitmap bundle size, for
example: it should be possible to create a bundle with just a single
64x64 bitmap and use it unscaled in 200% DPI, for example, rather than
scaling it up to 128x128 bitmap.
This used to work, at least in wxMSW, but stopped working after the
(perfectly valid, on their own) changes of 2508efdd6e (Initialize
wxMemoryDC with a default font, 2019-08-13), as this resulted in calling
wxApp::GetTopWindow() that can only be called from the GUI code.
Fix this by adding wxApp::GetGUIInstance() and using it in
GetMainTopWindow(), so that we only call GetTopWindow() if we actually
have a GUI wxApp object on which to call it.
Implement this in terms of a new virtual IsGUI() which seems slightly
better than, although roughly equivalent to, using wxDynamicCast().
Closes https://github.com/wxWidgets/wxWidgets/pull/2617Closes#19343.
The old API seems unnecessarily complex, it is simpler to just let the
application call ShowSortIndicator() itself from its
wxEVT_LIST_COL_CLICK handler, which needs to be defined anyhow in order
to actually sort the items, rather than require it to enable sort
indicator, explicitly set it initially and then remember to not set it
any longer in response to the column clicks.
Also make RemoveSortIndicator() non-virtual and implement it simply as
ShowSortIndicator(-1) because this actually simplifies the code too.
It doesn't seem right for ShowSortIndicator() to silently do nothing if
EnableSortIndicator() hadn't been called before, so make it enable the
sort indicators if they hadn't been enabled yet.
The alternative would be to assert in this function, but this seems less
useful.
Also add some comments to wxMSW version.
Don't do anything at all if nothing changes and if the indicator does
change, refresh only the header window and not the whole list control,
which seems unnecessary.
Don't use "const int" or "const bool" for parameter types, the "const"
here is ignored and using it is inconsistent with all the rest of the
library.
No real changes.
There doesn't seem to be any reason to not show sort indicators in the
columns of virtual list controls, so simply remove the test for
IsVirtual() in DrawSortArrow().
This allows d8ec0aa001 (Support sort indicators in wxListCtrl header,
2021-11-28) to work for wxListCtrl with wxLC_VIRTUAL too.
wxBitmapBundle-related changes introduced a bug when wxStaticBitmap
could be using an invalid handle (which manifested itself in not showing
any image on screen) if it was using wxBitmapBundle whose GetBitmap()
returned a wxBitmap that wasn't cached inside wxBitmapBundle itself.
In this case, this wxBitmap wasn't referenced anywhere after being
associated with wxStaticBitmap and so was destroyed, invalidating the
HBITMAP used by the native static control.
Fix this by keeping a copy of the bitmap in wxStaticBitmap itself. This
is not the most efficient, but is the simplest, solution.
The layout of the toolbar depends on the size of its bitmaps, which
changes when the DPI does, so call Realize() again when this happens.
This fixes the layout of the toolbars in the aui sample when moving it
between screens using different DPI.
wxPGProperty value edited in the first or last property of wxPropertyGrid
should be validated while attempting to navigate to the previous/next
property.
Closes#19315.
Don't use the ternary operator as t_str() doesn't return a pointer in
this build configuration.
Also remove outdated (and maybe even wrong) comment about MinGW headers,
as it's better to use a temporary variable just to avoid writing the
cast explicitly anyhow.
Closes#19338.
Include wx/textctrl.h, required here because wxTextCtrl is used as the
base class of wxPrintPageTextCtrl, explicitly instead of relying on it
being implicitly included by something else, as it happens in the
default build but not when validators are disabled.
Closes#19337.
Define __STDC_WANT_LIB_EXT1__ as early as possible to ensure that it's
defined before string.h is included by some other header without it.
Closes#19334.
This doesn't really change anything as the scaling factor is always the
same in both directions currently, but is more consistent with the other
places where Scale[XY]() are used.
This slightly amends the changes of 3787f55a6b (Add
wxDPIChangedEvent::Scale() and use it in this event handlers,
2021-07-11).
OpenVMS C++ compiler can't compile NanoSVG headers after including
wx/unichar.h, so include them as soon as possible, i.e. right after
wx/wxprec.h but before anything else.
This commit is best viewed with --color-moved git option.
This fixes the wxGenericCalendarCtrl on wxGTK3 where the SpinCtrl is
much wider than on other platforms and should also ensure that the
control is always big enough in all locales under Mac.
Closes https://github.com/wxWidgets/wxWidgets/pull/2604Closes#11444.
This is similar to the previous change to the generic version and simply
applies the same logic to the cells for which GetValue() returns null
value as for those for which HasValue() returns false.
In particular, don't draw them, as this would reuse the value of the
previously drawn item, which would be wrong -- just leave them blank if
PrepareForItem() returned false, which happens if GetValue() returned a
null value or a value of a wrong type.
We can't guarantee that GetValue() returns a valid value, even if
HasValue() returned true, so avoid calling SetValue() if it returned an
invalid one, as this risks triggering an assert failure and because this
function is typically called when repainting the control, there is a
good chance that we're going to reenter it while showing the assert
dialog box, resulting in an abort, which is not the best way to handle
GetValue() not returning a valid value -- especially when the generic
version doesn't do this, so the problem risks only appearing when
porting to Mac.
We call it inside the check ensuring that it is supported, so suppress
this warning (introduced in the recent e765756555 (OSX file dialog
extensions (#2592), 2021-11-26)) by casting the receiver to the generic
type, just as it's already done elsewhere in wxOSX code.
The bug was introduced in 9d86ba11e2 (Add support for wxBitmapBundle to
wxGTK wxNotebook, 2021-11-07) after which wxGtkNotebookPage::m_image
remained uninitialized if the page didn't have an image initially, so
fix it by simply initializing this pointer to NULL in this case.
It would arguably be better if wxGtkNotebookPage initialized all its
members in the ctor, but for now just fix the critical bug.
Closes#19332.
It's clear from the change history (relevant commits listed below) that these
are leftovers from code that is long gone.
ccdbdc8936 (Added native selection rectangle drawing., 2006-11-11)
05d9753817 (Just use the already existing wxRenderer::DrawItemSelectionRect(), 2006-11-14)
a4609ab847 (Implement wxRendererMac::DrawItemSelectionRect and move the generic wxTreeCtrl to using it to draw selected items., 2006-11-19)
It turns out that region being added to DC with enabled RTL layout needs
to be defined using mirrored device x-coordinates.
So if we have DC with RTL layout we need to create a temporary mirrored
region and pass it to the DC instead of the original one.
Closes#19325.
Update the language database from the canonical sources:
- It now includes most locales supported by Windows 10.
- It now also has the following attributes for each entry:
- BCP 47-like locale tag.
- Reference to canonical name for generic language entries.
- Language name in this language itself.
- Also add data file with list of language script identifiers and
aliases based on ISO 15924.
- And update genlang.py to handle all the new attributes and data.
Also move database-related methods of wxLocale to wxUILocale and
just redirect wxLocale methods to the new wxUILocale ones (they are
still preserved for compatibility).
Closes https://github.com/wxWidgets/wxWidgets/pull/2594
Re-introduce OpenSavePanelDelegate for filtering when wildcard is provided (Spotlight search field was not working correctly, if extension was not known)
(and on macOS 10.11 allow programmatically showing the extra panel)
see http://www.github.com/wxWidgets/wxWidgets/pull/2592 and https://trac.wxwidgets.org/ticket/19324
co-authered-by: Jeff Young <jeff at rokeby dot ie>
