The old code in wxToolBarBase::AdjustToolBitmapSize() forced the use of
the exact value of the requested bitmap size multiplied by the current
scale factor, which resulted in ugly bitmaps whenever fractional scaling
factor was used. It also used not immediately clear IncTo() call.
Simplify and improve it by handling the cases when we have a requested
bitmap size and we don't have it differently: if we do have it, just use
it directly, but only with an integer scale factor. And if we don't,
then simply use the bitmap size suitable for the current scale factor.
This seems to result in the most expected behaviour and, notably,
doesn't break the toolbar sample where the bitmap size can still be
toggled between small and big bitmaps on both normal and high DPI
monitors.
Also update the documentation: still recommend not to use
SetToolBitmapSize() at all, but don't claim that it forces fractional
scaling, as this is not the case any longer.
Using a section looks better and prepares for adding another one in the
upcoming commit.
Also remove a note about Motif file dialog limitation, nobody cares
about it any more anyhow.
Ensure that wxBitmapBundleImplSet and wxBitmapBundleImplRC use the same
logic for actually selecting the bitmap to upscale, and not just for
deciding the size that it must have, too.
No real changes, but this should make impossible for these functions to
diverge once again -- and also make it simpler to reuse the same logic
in any other wxBitmapBundleImpl-derived classes in the future.
Instead of taking an array of scales, call GetNextAvailableScale() to
get them.
This allows centralising the logic for returning the available scales in
a single place, where it will be reused in the upcoming commits.
Extract the logic determining the scale to use in a reusable
DoGetPreferredSize() function to allow reusing it in other places.
There are no real changes here, this commit just moved the existing
code to the new function, but because it also changed it from using
wxSize to double, even git --color-moved doesn't show it as an actual
move.
If a wxEvent-derived class documentation lacks "events" category,
the class will not appear in the Events class list.
The "events" category is still missing in several event classes
(e.g., palette events or wxRibbonToolBarEvent), but those lack
actual documentation aside from just methods declarations anyway.
Even though it's better to not specify the preview frame size at all,
the size should still be used if it was explicitly specified, but this
didn't happen any more after the addition of the call to Fit().
Fix this now by only doing the equivalent of Fit() if no size was
explicitly given.
Also add advice about not setting the size explicitly to the
documentation.
Unlike direct tests of __cplusplus, using this macro also works with
(recent enough, i.e. MSVS 2015.3 or later) MSVC versions, even if
/Zc:__cplusplus is not used.
This simplifies some checks and makes some other ones (notably the check
for C++20 used before wxALLOW_COMBINING_ENUMS macro definition) work
with MSVC versions with C++20 support as intended.
This is easy to do and can be useful when using an atomic initialization
counter.
The only platform where not returning the new value might be more
efficient than returning it is Solaris which is not really relevant any
more and on all the other platforms the functions we were already using
provided this value already (or almost, in case of using gcc builtins,
when we just have to use a different one).
The default type doesn't really matter after the previous commits, as
the renderer accepts both wxBitmap and wxBitmapBundle (and also wxIcon)
in any case anyhow, but it seems better to use the preferred type as the
default one.
Also make the documentation more useful, although an example is still
lacking.
Instead of checking for the exact variant type match, call the new
IsCompatibleVariantType() virtual function, which still does the same
check by default, but can be overridden to allow other types as well if
they're accepted by the renderer.
This will be soon used to allow accepting both wxBitmap (which must
still be accepted for compatibility) and wxBitmapBundle (which is the
simplest way to support high DPI) in wxDataViewBitmapRenderer at once.
This is intentional and won't be changed, although we could, perhaps,
add a wxGetDST() function or similar to make it easier to take DST into
account as well.
Closes#22399.
There are several ways to do it, and it's not clear which one of them
should be illustrated here, but it should definitely be one that works.
Closes#22389.
Don't take the value of "mask" parameter of wxImageList constructor too
prescriptively, it predates support for alpha in wxWidgets by many years
and was never meant to actually suppress using it.
Instead, do the best thing we can in all cases, i.e. use alpha if it's
specified and supported and use mask otherwise. But only create the mask
from light grey colour if we have nothing else if "mask" is true in
wxImageList constructor, as this is a potentially destructive action
that must not be performed if the user has explicitly decided to set
this parameter to false.
Incidentally fix handling of alpha with comctl32.dll v5 (which is used
in the absence of any manifest) by converting it to a mask in this case:
this is not ideal, but better than just using black background as it
happened before, and restores pre-3.1.5 behaviour.
Also simplify the generic version which just has to create the default
mask if necessary and doesn't have to do anything at all in all the
other cases.
Note that these changes required relaxing some of the existing unit
tests as wxMSW implementation now can add alpha channel to the bitmaps
that didn't have it -- but this is a more useful behaviour, and so it
makes more sense to adapt the tests to it rather than doing a less
useful thing just to conform to the tests.
This commit is best viewed with git --color-moved
--color-moved-ws=ignore-all-spac options.
Closes#22349.
Add information about the recommended way of using wxFrame
as a form, i.e., to not create the input controls as its
direct children but use wxPanel for this instead.
Closes#22395.
Reuse the same code for handling mouse events for both rows and columns
instead of duplicating almost (but not quite) the same code for both of
them.
As part of resolving the inconsistencies between the two versions, add
wxEVT_GRID_ROW_AUTO_SIZE corresponding to the existing event with the
same name for the columns.
Closes#22380.
Make wxDC and wxGraphicsContext DPI aware, i.e. add {From,To}DIP() to
them too and make the values returned from Get{DPI,PPI}() consistent
with wxWindow.
Also improve CMake build: add support for finding Cairo when not using
GTK, fix a warning when creating the inplace-config, and mark some
variables as advanced.
See #22346.
Add wxSharedClientDataContainer class storing ref-counted client data
and use it instead of plain wxClientDataContainer in wxGridCellAttr,
wxGridCellEditor and wxGridCellRenderer classes.
This allows to keep the same client data associated with many grid cells
without having to make many copies of it.
Previously it interpreted its argument as being in DIPs, which was
perhaps more convenient, but inconsistent with most of the other
functions and broke the general rule that FromDIP() should be used with
all hard-coded sizes.
Update the sample to use FromDIP() when calling it now, improve the
documentation and fix a bug in AdjustToolBitmapSize() which resulted in
not increasing the bitmap size when moving toolbar sample using "large"
toolbar size from a standard DPI display to a high DPI one: the old code
considered that the new size was the same as the old one and returned
before comparing it with m_requestedBitmapSize, which resulted in the
bitmaps not changing size at all instead of doubling their size as they
were expected to.
