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.
Doing this must reset any existing image list, as some controls (notably
wxTreeCtrl) use the image list internally and keeping using it would
still show the old images even after resetting them.
Since the changes of 4d76a87015 (Make wxSearchCtrl inherit from
wxTextEntry in all ports, 2023-07-09, see #23697) GetEditHWND() returned
null for wxSearchCtrl which was considered to be correct because all
wxTextEntry functions were supposed to be forwarded to wxSearchTextCtrl
anyhow.
This wasn't really correct, however, as GetEditHWND() was also called
from SetHint(), resulting in an assert failure and falling back on
generic hint implementation which, while mostly working, suffers from
some problems that the native implementation doesn't have.
So make this function return the actual HWND used by the associated text
entry to fix this and allow SetHint() to work as before and also
forestall any problems due to not having the right HWND in the future.
See #23983.
Closes#23975.
This is currently implemented for single line control only. But unfortunately the
wxEVT_TEXT_MAXLEN event is only emitted when the Qt version used is 5.12 or higher.
Having this line is not useful at all as it doesn't contain any
information and shouldn't be filled in the future as git-shortlog can
provide the information about people who changed the given file more
more reliably than consulting the comments in any case.
Keep the non-blank lines for historical purposes.
QtSet{Min,Max}Size() were added for use by Set{Min,Max}Size() and
DoSetSizeHints() overrides. and since we have canceled overriding
Set{Min,Max}Size() in previous commit, there is no need to keep them
around without good reason.
This partially reverts commit 3c68696 (Make wxTopLevelWindow::SetSizeHints()
work in wxQt) because it breaks some wxSizer tests. and more importantly, it
breaks the documented behaviour of SetMinSize() which says:
Notice that calling this method doesn't prevent the program from making the
window explicitly smaller than the specified size by calling SetSize(), it just
ensures that it won't become smaller than this size during the automatic layout.
Using both wxDEPRECATED_MSG and wxNODISCARD for some reason breaks
compilation with clang (when using C++17 or newer standard).
Since wxBasicString::Get() is deprecated, one warning should be enough
so just remove wxNODISCARD from the method declaration.
Closes#23952.
Also make it clear that wxCHOICE_{HEIGHT,WIDTH} constants are not really
used for anything.
Closes#23949.
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
The new function only returns true if the catalog could be really
loaded and not if it is considered not to be needed because the message
ID language (which is typically "en-US") happens to be present in the
preferred UI languages list (which seems to always include "en-US" in at
least Western European MSW).
This allows to distinguish, albeit in a rather awkward (but
backwards-compatible) way between having a translation for the given
language and not needed such translation.
It is still not clear if it is really correct to return "en-US" from the
list of preferred languages even if the user has never intentionally
configured the OS to indicate that English is acceptable, but at least
now we can work around this issue and use AddAvailableCatalog() in
AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo
if the versioned wxstd-x.y.mo file is really found instead of never
doing it, as was the case until now (see #23886).
Also add GetBestAvailableTranslation() helper which seems more useful
than the existing GetBestTranslation() one and is similarly related to
it.
See #18227.
Improve consistency of checkboxes in wxListCtrl between virtual and
report mode, and between the generic and MSW implementation, see #23869.
Also disable WS_EX_COMPOSITED for virtual wxListCtrl because it
generates an endless stream of cache events, see #23878.
See #23890.
