Some versions consist of four parts with the last part being called the
revision or build number. wxVersionInfo is now able to save such a
fourth number.
Add another compatibility implicit constructor to allow the existing
code, directly passing XPM data to various functions that used to take
wxBitmap or wxIcon and now taking wxBitmapBundle, to work.
Closes#22566.
Don't change the window size automatically if the application handled
wxEVT_DPI_CHANGED event to allow it to choose a better size than what is
suggested by MSW itself.
Closes#19152.
Make wxINVERT logical function work in at least some circumstances with
wxGTK3/X11 and use this to make wxSplitterWindow and wxSashWindow
separator visible during resizing.
See #22546.
Closes#16890.
HasAlpha() was already available in most of them, now ensure that it's
present in all of them, especially as it has a reasonable default
implementation.
UseAlpha() was only present in wxMSW and wxOSX and still remains only
implemented there, but provide at least a stub for it elsewhere as well
to avoid problems such as that of #17393.
See #22545.
Closes#17397.
Neither of these methods was actually ever used after the changes of the
last two commits (and they hadn't been used when not using wxGTK even
before), so don't force the user-defined model classes to override them.
Also stop using them, as the stub versions don't return correct values
any longer.
Still keep the virtual functions in the base class for compatibility
however as it doesn't cost us much and avoids breaking the existing code
using "override".
This is implemented in Cairo and CoreGraphics renderers only, but this
is still useful as these renderers are used on the platforms where wxDC
wxINVERT logical function is not supported and this composition mode can
partially replace it.
Check that it consistently returns 0 in the wxLC_ICON and
wxLC_SMALL_ICON modes under all platforms.
Document the behaviour of this function in all modes.
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).
