wxObjectDataPtr::operator=() didn't handle self-assignment correctly,
i.e. could delete the object when doing "x = x".
Fix this by incrementing the reference count before decrementing it on
possibly the same object to ensure that it never reaches 0.
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
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.
On macOS >= 11 wxListBox has a new layout because underlying
NSTableView has a new style with padding so we need to move
the point to be tested to another position.
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.
OpenVMS build was broken by 303d899cc0 (Make STL-based wxList more
compatible with the default one, 2021-09-02), try to blindly fix it by
casting the element to the same type it had had before.
Check that Find() of a list declared using WX_DECLARE_LIST_3 (as
wxWindowList is) can be passed a pointer to the base class object and
still compiles and works correctly.
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.
Some existing code relies on wxEVT_TEXT being defined after including
just wx/combobox.h too, so just keep this formally unnecessary but by
now impossible to remove #include removed in d3eafa4d18 (Fix compilation
of wxFormBuilder-generated code using wxTE_XXX, 2021-07-14).
See #14132.
Closes#19264.
When adding characters to a long word-wrapped line one by one, there was an hotspot in wxString(const wxString&) and wxString::replace.
When rendering or getting caret position, each broken line from a long line of text was being processed separately. Before handling each line, some preprocessing is done: replace a character by another character and make uppercase if necessary.
Before, this way happening for each line:
* make a copy of the whole long string
* preprocess that copy of long string
* get the needed substring of it
Now, we do this in most cases:
* get the needed substring of the long string
* preprocess that short string
When one inserts one big line to a wxRichTextCtrl that is too long (say 300k words of average size 9), then wxRichTextCtrl could freeze for a few seconds. It could also freeze again when the control is resized (such that word wrapping is triggered again).
Problem: `wxRichTextParagraph::AllocateLine(int pos)` can be called many times. Each call triggers `m_cachedLines.Item(pos)`, which traverses the linked list. As a result we get quadratic time complexity.
In this commit, we improve the function by also caching the lines in a vector, which supports random access in O(1) time.
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.
Don't use GetVolumeSeparator() to combine UNC or GUID volumes with
paths, this doesn't work because this kind of paths doesn't contain
colons at all.
Update the documentation to mention this.
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.
