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 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.
Range may be -1 when wxSHOW_SB_ALWAYS is used, see
wxScrollHelper::DoAdjustScrollbar(), so check for it to avoid spurious
asserts in this case.
Closes https://github.com/wxWidgets/wxWidgets/pull/2540
When touch events were enabled, normal mouse move and click events were
not generated any longer. Fix this by doing the following two things:
First, emulate the LeftDown, LeftUp, and Motion events, that are no
longer triggered when using the "touch-event".
In addition, remove GDK_BUTTON1_MASK in the press callback, that is
never set when using a mouse, but that is set for some reason by GTK
when using a touchscreen.
See https://github.com/wxWidgets/wxWidgets/pull/2539Closes#19265.
Signed-off-by: Thierry Bultel <tbultel@free.fr>
This function is currently used for relatively small icons in
wxArtProvider and wxSearchCtrl, so it shouldn't be a problem to use
wxIMAGE_QUALITY_HIGH from performance point of view and if it ever does
become a problem, the application could easily use wxImage::Rescale()
with a different option directly instead.
Define a single function and use it in both wxArtProvider and (the
generic implementation of) wxSearchCtrl instead of repeating the same
code elsewhere.
Note that another, but slightly different, version of RescaleBitmap()
still remains in wxPropertyGrid.
Deprecate undocumented wxArtProvider::RescaleBitmap() which is
completely useless now.
No real changes, this is just a refactoring.
Use native scrolling under MSW, just as we already did under X11,
instead of our own version which doesn't work correctly when scrolling
using the mouse wheel.
See https://github.com/wxWidgets/wxWidgets/pull/2525
In wxComboBox::SetString() implementation for wxMac the item is
first removed from the list so its selection is invalidated.
We have to retain it so we need to re-select just inserted item.
This still doesn't work if the file doesn't exist, but at least shows
the correct file name if it does exist, which is better than nothing and
the best we can reasonably do when using the native control.
Closes#19163.
This comes at the price of breaking compatibility and returning
"\\share" rather than just "share" from wxFileName::GetVolume() for the
UNC paths. This breakage seems justified because it is required in order
to allow application code to distinguish between paths "x:\foo" and
"\\x\foo", which was previously impossible as GetVolume() returned just
"x" in both cases.
Document this change, adjust the existing checks for the new GetVolume()
semantics and add a new test which passes now, but didn't pass before.
Closes#19255.
This commit is best viewed ignoring whitespace-only changes.
Replace the workaround introduced as a "temporary fix to avoid breaking
backwards compatibility in 2.8" back in 9e1c7236e0 (don't treat foo in
c:\\foo\bar as network share, 2006-12-17) with a better solution
proposed in the comment in that commit, i.e. don't even try to extract
the volume from the path if we already have the volume separately.
This commit is best viewed ignoring whitespace-only changes.
Creating a directory with the leading path separator unexpectedly
created it under the current directory rather than in the root of the
current drive under MSW, due to the path being considered relative, in
spite of starting with the path separator, because it didn't have the
volume.
Fix this by avoiding the use of IsAbsolute() in Mkdir() and checking for
m_relative instead, as it seems the safest possible fix for this bug
because changing IsAbsolute() to return true in this case might change
the behaviour of the existing code.
Closes#4470.
Extend the existing workaround to work not only with explicitly
wxPATH_DOS paths, but with paths implicitly using the DOS format due to
it being the default format for the current platform.
Closes#19261.
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.
There doesn't seem to be any point in using local "customBorder" instead
of member "m_widthCustomBorder", so remove the unnecessary local
variable and use the member variable instead.
No real changes.
Don't set default width every time the column is updated, as it happens
e.g. when it's clicked by the user, but only when it is created, by
moving the code added in 96d36383bd (Use sensible default column width
in generic wxListCtrl too, 2021-08-17) from SetItem() to the ctor of
wxListHeaderData.
Closes#19256.
Initialize m_ribbonBar added in the previous commit to NULL before
setting it to the correct value later, when wxRibbonButtonBar is fully
created.
See #19249.
Co-Authored-By: Maarten Bent <MaartenBent@users.noreply.github.com>
Fix crash introduced by 8e8a68c1b (Move code accessing bitmaps to
wxRibbonButtonBarButtonBase too, 2020-02-07) which start using
GetAncestorRibbonBar() in wxRibbonButtonBar code, without taking into
account that we may have no ribbon bar ancestor when the button bar is
shown in a popup frame, as it happens when there is not enough space to
show it fully in the main window itself.
Remember the ribbon bar in a member variable, relying on the fact that
we must have it in our parent chain when constructed, and just use it
later to avoid this.
Closes#19249.
