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.
This sweeps under the carpet the regression which resulted in bitmaps
returned from wxArtProvider::GetBitmap() not looking the same since
starting to use wxBitmapBundle in AUI, but OTOH it just doesn't seem
possible to both preserve the compatibility and allow actually using
appropriate, not scaled, bitmaps in different resolutions.
The new code is as simple as the old version, follows the official
advice to use GetBitmapBundle() rather than GetBitmap(), and looks good
in high DPI, which should compensate for the behaviour change.
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.
wxAuiToolBar::SetToolBitmapSize() doesn't do anything and never did ever
since it was added back in 1154f91b6a (added wxAuiToolBar, 2008-08-24),
so don't bother calling it, this just makes the sample code confusing as
no effect from passing different sizes to SetToolBitmapSize() can be
seen during run-time.
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.
It seems like this function will need to be used in every implementation
of EVT_LIST_COL_CLICK handler when using sorting, so it makes sense to
provide it in the library itself.
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.
It seems that the default value of NtfsDisable8dot3NameCreation registry
value is 2, and not 0, since a very long time (at least Windows 7), so
the wxPATH_NORM_LONG test was never actually executed.
Change the check guarding it to check if the value of the key is
different from 1 instead of checking that it is 0, as the test can still
succeed on the systems where this is the case.
Of course, it can also fail, if short names are disabled for the current
volume, but let's see if this is a problem in practice before doing
something more complicated to deal with this case.
This file already exists in the test directory, as it's used by another
test, so just use it instead of relying on the existing of mkinstalldirs
in the parent directory, which is not guaranteed as CMake build runs the
tests from a different directory, which is not the immediate child of
the top source directory.
No real changes, just use a more clear and longer (which will be
important for the next commit) name for a test file.
Remove the non-existing samples/console/testdata.gc from make_dist.mk
(there are other non-existing files still referenced there).
This option is disabled in the GUI, but users can still specify it on the
command-line. Never add the linker flags to prevent errors (unsupported option
'-static-libgcc') or warnings (argument unused during compilation:
'-static-libstdc++').
Closes https://github.com/wxWidgets/wxWidgets/pull/2612Closes#19330.
Using this ctor is more convenient than using the default ctor and then
calling SetMin() and SetMax().
Document the new ctor and add tests showing that minimum and maximum
values are actually respected.
Closes https://github.com/wxWidgets/wxWidgets/pull/2610
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.
