Override OnImagesChanged() to call UpdateImageListIfNecessary() even in
wxGenericTreeCtrl for now, although in the future it would really make
sense to stop using wxImageList in its implementation and just use
wxBitmapBundle directly instead.
wxMSW is the only one which really needs an image list, as it's required
by the native control.
Also update the sample, even though it doesn't look very nice because
its icons are only available in a single size, so we have to always
scale them.
This was added way back in 618a5e382a (Applied Greg's patch to tree
control and related., 2001-08-18) for some reason, but probably was
never needed and definitely isn't any more.
Use HAS_GENERIC_TREECTRL for testing whether we're actually using it or
not instead of checking for USE_GENERIC_TREECTRL and then port names
with a native control, which was done inconsistently, as it included
wxQt in one place, but not the other one.
Also avoid repeating CreateButtonsImageList() declaration twice, as this
resulted in having unbalanced curly braces in this file, which was just
unpleasant.
No real changes.
This new function will allow selecting the bitmap of the most suitable
size and automatically react to DPI scale changes (although this hasn't
been implemented yet) in all controls using image lists.
For now, only wxNotebook in wxMSW has been updated to work with it, the
other classes and ports will be updated to override OnImagesChanged()
instead of SetImageList() later.
Also update the notebook sample to use SetImages() rather than
SetImageList() -- which means that it doesn't show the icons any longer
in non-MSW ports, which haven't been updated yet.
These functions allow avoiding using wxImageList explicitly in a couple
of places.
No real changes, this just prepares for adding new API not based on
wxImageList.
These resource files didn't appear in the .bkl ones and so were not used
at all and were not worth being used anyhow, as they didn't differ
significantly from sample.rc.
This is required for high resolution bitmaps support and it will be
needed in other samples too, so use it for all of them.
This probably will result in some problems due to remaining bugs with
high DPI support, but it should make them more noticeable and so should
help with finding and fixing them.
Using bitmaps of preferred size avoids scaling and results in much
better appearance, so add methods allowing querying the bundle about the
bitmaps it supports and implement them in the various implementations.
This is not actually used anywhere yet, but will be soon.
Take wxBitmapBundle in wxButton::SetBitmapLabel() and related functions
in order to be able to associate several bitmaps to be used in different
resolutions with the button, instead of just a single bitmap.
Pass wxSize by const reference instead of "const" value.
Note that passing wxSize by value might be not such a bad thing,
actually, but we use const reference for it everywhere else, so do it
here as well for consistency (and the original intention was to do it
like this, missing "&" was just a typo subsequently propagated through
copy-pasting).
No real changes.
Passing non-const data is inconvenient and error-prone, as data can't be
used again after it was modified by Nano SVG, which resulted in the
button using SVG bitmap not working any longer in the toolbar sample
after recreating the toolbar.
So make it easier to do the right thing, while still keeping the
overload taking non-const data for the situations when avoiding an extra
copy is worth it.
Add nanosvg submodule and use it in the generic implementation of this
function.
This is incomplete yet and, notably, doesn't cache the rasterized
images, but already shows that using SVG images works (at least in the
toolbar sample).
This actually reverts the sample to the version in master, which used
wxBitmap::Get{Width,Height}(), but just replaces "w" and "h" variables
with a single "sizeBitmap" one.
Also stop hard-coding (100, 100) position for it, there is no real need
for it and it's better to let the window be positioned automatically.
No real changes.
This first version provides only a generic implementation of
wxBitmapBundle using a collection of bitmaps and only supports using it
in wxToolBar in wxMSW and wxGTK.
More methods of creating wxBitmapBundle will be provided later and more
functions taking wxBitmap will be changed to take wxBitmapBundle later
too and, of course, all the other ports will be updated to use the new
API too.
Unlike the existing wxHAS_IMAGES_IN_RESOURCES constant defined only
under MSW, the new one is also defined under Mac and could be defined
for the other platforms/ports later (e.g. wxQt could probably support it
too).
It's unfortunate that two very similar constants are needed, but it
doesn't seem wise to change the meaning of the existing constant, as
this would change how the commonly used wxICON() and wxBITMAP() macros
behave and would break all our own samples that use them for their frame
icon but don't embed this icon into the bundle resources under Mac.
Do change the toolbar sample to use the new constant however, as this
one does include the bitmaps it uses in its bundle under Mac.
Update the sample for the 21st century (with just a bit of delay) and
use PNGs under all platforms instead of using BMPs under MSW and XPMs
elsewhere.
Copy PNG icons from Tango, even if we already have almost of them in
art/tango because we plan to also use "2x" versions of them in this
sample soon.
Add wxComboCtrl::SetMainControl() which can be used to use some other
window instead of the default wxTextCtrl as the main window of the
combo control.
Update the sample and the documentation to show the new function.
For some reason, we used "vc_x64_lib" as the output directory for the
libraries, but "vc_mswu_x64" as the output directory for the samples.
Place the arch suffix, i.e. "_x64" part, always after the compiler
prefix (possibly including version), for consistency with both the
library output directories and with MSBuild project files, as
build/msw/wx_setup.props uses $(wxCompilerPrefix)$(wxArchSuffix)_...
as wxIntRootDir value.
Add wxUILocale class providing functionality which can be implemented
portably for all major platforms, including macOS, and doesn't force
the change of the global C locale, unlike wxLocale.
See https://github.com/wxWidgets/wxWidgets/pull/2464
It seems inconsistent to have MSVS 2019 solution for the main library
itself, but only MSVS 2017 (and earlier) one(s) for the sample and the
tests, so add MSVS 2019 solution to them too.
This is going to be just annoying on the platforms where spell checking
is not supported, so show the message inside the text control itself
rather than popping up a message box.
Also put a misspelled word in the control from the very beginning to
show that it is highlighted.
Remove a separate "bool enable" argument of EnableProofCheck() and use
wxTextProofOptions::IsSpellCheckingEnabled() to decide whether the
checks should be enabled or disabled.
Also remove wxTextProofOptions ctor and provide named static factory
functions for creating the objects of this class with clearly defined
meaning.
