This corrects a problem introduced in 11ed91af8f (Add missing default
constructor of wxFileDialog in wxMSW, 2023-12-03) as m_data remained
uninitialized when default ctor was used.
See #24113.
wxIntProperty::DoValidation() overloads for wxLongLong_t and wxULongLong_t
parameters are not supported because for these types there are no direct
conversions to wxVariant.
Arguments of such types will be handled by overloads for wxLongLong
and wxULongLong.
This code was already used for Ctrl-C handling, refactor it into a
separate function that can be called from the application now.
This commit is best viewed with --color-moved-ws=ignore-all-space Git
option.
Closes#24124.
Although wxGenericTreeCtrl is not used under MSW by default, it still
doesn't hurt to adjust its metrics when DPI changes there.
Note that this shouldn't be done for the platforms using DIPs.
The icons positioning was broken by 53b4f4ddf2 (Use physical size in
wxImageList, 2023-11-03) because the logical size was calculated
incorrectly in the case when wxImageList was used for the icons and
ended up being 8x8 for 16x16 icons when using 200% scaling, which was
clearly wrong and resulted in the icons not fitting in the space
allocated for them because they actually took 32x32 physical pixels due
to scaling of all bitmaps from wxImageList.
Fix this by correctly taking account of the window DPI scale factor.
This is a bit roundabout because using FromPhys() later just undoes
this, but it allows to keep using the same code when using wxImageList
and wxBitmapBundle for storing bitmaps and so is simpler.
Note that we must only do this when wxImageList was provided by the
user, i.e. with the legacy code, but not when it was created internally
in addition to wxBitmapBundle, as in this case we recreate it on DPI
change using the correct, DPI-adjusted size, already, so restrict this
scaling to the case when we don't have wxBitmapBundle only.
This commit is best viewed ignoring whitespace-only changes.
This parameter was always "true" in the existing calls to this function
and the underlying UseClippingView() didn't support passing "false" to
it anyhow, so it seems simpler and more clear to just remove the
parameter.
It also avoids clang warnings about it being unused.
No real changes.
This fixes warnings about MAC_OS_X_VERSION_11_0 not being defined when
using older SDKs, as 21da0e128d (Change wxRendererNative to use
NSCell-based methods under Mac, 2023-11-12) used a wrong name for the
version constant: since macOS 11 these constants don't use "X" in their
names any longer.
Remove this and add a comment to the place where we define them to
document this not quite obvious naming convention.
Postpone the creation of the QStatusBar fields until the first call to
SetStatusText(). This is to account for any field control added by the
user and also to avoid having to call UpdateFields() multiple times.
wxSTB_ELLIPSIZE_XXX and wxSTB_SHOW_TIPS supports are also implemented now.
The statbar sample is also updated: The OnSize() handler is removed because
it doesn't do much. that is: it is defined to keep the bitmap centered in the
status bar field it occupies if it is resized. but this is already done by the
wxStaticBitmap control, at least under wxMSW, wxGTK3 and wxQt.
This is not necessary and, more importantly, results in a crash if you try
to recreate the status bar (which can be seen in the statbar example)
Also remove leftover QList declaration
This includes a static function to calculate Easter that can be used for
other authorities.
Document the wxDateTimeWorkDays and wxDateTimeHolidayAuthority classes.
Closes#24094.
This allows user codes to simply designate where their controls should
appear in the status bar without the need to handle wxEVT_SIZE
themselves.
They can still handle the event if the default positioning does not meet
their needs, but the new API is simpler and can be implemented for wxQt.
Closes#24092.
Fix wxBitmapBundle::FromSVG(), which renders incorrectly on GTK and add
wxHAS_PREMULTIPLIED_ALPHA to make the code dealing with alpha more clear
and correct.
See #24097.
We need to use a native clip view for things to behave correctly under
this OS version, otherwise scrollbars can be overdrawn by the window
contents.
Closes#24067.
Closes#24073.
And do nothing in this function if the arguments had been already
initialized, as it will make it more convenient to call from other
places.
No real changes.
All previous relevant platform-specific tests have been changed to use this
symbol. Also, samples/image now premultiplies conditionally, correcting a
visual anomaly on wxGTK.
The problem was: wxClientDC draws in a QPicture owned by the DC. In the destructor,
QtPictureSetter sets the picture to be used by the associated window and generates
a paint event, then resets the picture when it goes out of scope before the paint handler
has a chance to replay the image. In this commit, this setup is changed so that window
owns the picture instead and is responsible for deleting it when it is actually used.
Replace user-specified empty constructors and destructors with the
compiler-generated versions, which has a number of advantages for code
generation, in addition to being more clear.
Closes#22965.
Closes#24058.
Refactor wxImageList and convert it to use physical pixels and
add support for high DPI state images wxTreeCtrl using the new
wxImageList.
See #24000, #24033.
This is similar but not totally identical to the existing
GetNextVisible() as it doesn't require the initial item itself to be
visible (notably, it could be the hidden virtual root).
It is also more efficient than the old GetNextVisible() implementation
calling GetNext() in the loop until finding a visible item, as it avoids
looking inside collapsed items in the first place.
Just check if the scale factor has changed when getting a "configure"
event for a TLW as we're guaranteed to get one when the scale factor
does change, according to GTK documentation (and it does seem to work).
Closes#19290.
Although this is not ideal, it may still happen and sometimes can even
give acceptable results, e.g. using (16, 32) and (24) bitmap bundles
can actuall works nicely enough at x2 scaling if 16px bitmaps are
upscaled by the factor of 3.
To make this work, request the explicit physical bitmap size and
override its scale factor to ensure the resulting bitmap has the correct
logical size.
The new function does the same thing as the Mac-specific
OSXMakeDPIFromScaleFactor() that it replaces but is also defined in
wxGTK where it will be used too.
Take const pointer in GetConsensusSizeFor(), which only uses this
parameter to get the DPI scale factor, and CreateImageList(), using it
only to pass it on to GetConsensusSizeFor().
No real changes.
This seems to be the only way to fix using this class, which is
fundamentally incompatible with high DPI support, with bitmaps of
different logical but identical physical sizes.
By using physical size we ensure that the code chopping up the provided
bitmap in multiple images doesn't do it with the bitmap having the same
physical size but a different logical size from all the other bitmaps.
And, conceptually, logical size of the bitmaps in it really shouldn't
matter to the image list as it doesn't have a scaling factor and so
can't do anything useful with the logical size.
Moreover, we can't add wxImageList::SetScaleFactor() neither because
this class is, by design, supposed to be shareable between different
controls which may use different scale factors, so it doesn't make sense
to speak of the scale factor of the image list itself.
This undoes the changes made in the generic implementation back in
c374eefd34 (Fold wxOSX-specific wxImageList into generic version,
2018-10-30) and also eb52e86553 (Take into account scale factor of
images added to wxImageList, 2021-04-03).
Also update a couple of places where wxImageList is still used to use
physical sizes. Unfortunately some others can't be easily fixed, e.g.
global wxFileIconsTable would have to be completely rewritten.
Finally, add a unit test checking that things work as expected now:
previously the size of 24x24 bitmap in the image list containing
(scaled) 32x32 bitmaps would be 21x21 due to sub-bitmap extraction
kicking in.
Closes#23994.
No real changes, just refactor the code to reset all drag-related
variables in a single function instead of doing it manually in several
places.
As this function also resets m_clickTab, which could previosuly remain a
dangling pointer, change the code to get its value before calling it.
Ensure that all of them are initialized, including m_clickTab, which
didn't seem to be always initialized before.
No real changes (as m_clickTab doesn't seem to have been used before it
was initialized).
Add these functions for consistency with SetStateImages() and to avoid
using GetStateImageList() in the treectrl sample, which can now use
GetStateImageCount() instead.
Unlike the existing SetStateImageList() function, the new one allows to
provide the high-resolution versions of the state images too.
Update the treectrl sample to use the new API.
Closes#23993.
