Add wxMessageOutputWithConv mix-in class to avoid duplicating the same
code in wxLogStream and wxMessageOutputStderr.
Also derive wxLogStderr from wxMessageOutputStderr to reuse its code
without having to create a temporary object of this type (which will be
more expensive now that doing it involves creating a heap-allocated
conversion object copy).
This commit refactors the overloads of cMB2WC() and cWC2MB() methods
taking raw pointers and buffers to reuse the same code and fixes the
wrong length of the buffer returned by cWC2MB(wchar_t*) overload for
conversions using multiple bytes to represent the NUL terminator
character (it previously was wrong for UTF-16 and UTF-32 conversions due
to wrongly subtracting 1 from the length when creating it instead of
correctly subtracting GetMBNulLen()) and the wrong length of the buffer
returned from cMB2WC(char*) overload where no adjustment for the
trailing NUL was done at all.
Also return simple default-constructed buffers from these methods in
case of failure instead of using wxScopedCharBuffer::CreateNonOwned()
which is less obvious and less efficient (even if the latter probably
doesn't matter here because it's only done in case of an error).
Finally, add tests checking that using WC2MB() or either of cWC2MB()
overloads returns the buffers of the same length and with the same
contents.
We can only use utf8_length() if the conversion used with this object
uses UTF-8 too, otherwise we still need to do the conversion to find out
how many bytes does the string content take in the given encoding.
See #17985.
The Darwin linking problem mentioned in the comment doesn't exist in any
of the still supported macOS versions, so it doesn't make sense to
continue working around it.
Initialize m_pos correctly when using an existing, and hence possibly
not empty, string (and not the internal one which is always empty
initially). The old code was totally wrong as it divided the string
length by the size of wxChar instead of multiplying by it, but doing
this could have been wrong too with UTF-16 and surrogates, so use the
conversion object to compute the real length of the string
representation in the corresponding encoding.
Add a simple unit test checking that this works as intended.
Closes#17985.
Because top windows can (and do) act as parents for certain dialogs, a
window already pending delete shouldn't be explicitly reported as the top
window because all dialogs which would use it as a parent
would be destroyed at nearest idle cycle.
Closes#17982.
Check for the record size before subtracting it from the end position:
the former must be smaller than the latter for all valid ZIP files and
not performing this check could result in an integer overflow error from
the undefined behaviour sanitizer for bad input.
Credit to OSS-Fuzz: this solves its issue 3828.
Zip filenames containing non ASCII characters will be marked with
bit 11 in the general purpose flags and will use UTF-8 encoding.
By only setting the flag when non ASCII characters are used the
created archives should be binary identical to previous versions.
The old behavior can be achieved by explicitly using wxConvLocal
with the constructor. This should also ensure that
existing code using a custom wxMBConv should work as before.
Skip memcpy() call if its source and destination would overlap: this is
not allowed and is correctly flagged as an error by address sanitizer
and is unnecessary anyhow as we're certainly not going to find the magic
value in fewer than 3 remaining bytes.
Credit to OSS-Fuzz: this solves its issue 3794.
Provide native implementation of this function instead of using the ad hoc one
in common code, which didn't really work -- so remove it completely now.
Closes#17189.
Fix comparing items with checkboxes in wxTreeListCtrl and make it
simpler to correctly implement item comparison in other
wxDataViewCtrl-derived classes.
See https://github.com/wxWidgets/wxWidgets/pull/558
This allows to hide the long (and possibly not fitting on the screen)
call stack by default to avoid intimidating people not used to it and
provides a much more clear way to ignore the subsequent asserts, by
clicking a dedicated checkbox instead of having to choose the "Cancel"
button which didn't make much sense.
See #15430.
This makes more sense than the default default (sic) "Yes" button,
pressing which accidentally could kill the program if not running under
the debugger.
This should have been part of 55fd62c1e3
which only updated the default assert handler, but not the one used by
default in all GUI applications, for some reason, see there for more
explanations.
Do this now to ensure that after pressing "Yes" in the assert failure
dialog, the debugger opens at the assert location and not deep inside
wxWidgets code.
See #11184.
Export this class, which was only used internally by wxTreeListCtrl
before, so that user code can use it for its own columns with custom
wxDataViewCtrl models.
At least in wxMSW wxPen::GetStipple() returns a non-null (but invalid)
bitmap even when pen style is not wxPENSTYLE_STIPPLE, so don't test for
this bitmap when creating a wxGraphicsPen from a wxPen but for the style
directly.
This avoids using this invalid bitmap later in D2D code, where it
resulted in assert failures.
Also add a similar style test before calling wxPen::GetDashes() for
consistency, even if it doesn't seem to be strictly necessary.
See https://github.com/wxWidgets/wxWidgets/pull/553Closes#17958.
Using smart array class is better than using ad hoc scope guards for
freeing memory in any case, but in this particular case it also helps to
avoid g++ 7 -Wnoexcept-type warnings due to type of free() changing to
become "void(*)() noexcept" in C++17.
This is a helper method used only in wxWidgets itself and only once, so
just inline it at the point of use to avoid exporting an unnecessary
function in the public API.
It doesn't make much sense to require all the graphics backends to
create wxGraphicsPen from either wxPen or wxGraphicsPenInfo when the
former can be handled just once in the common code.
So do just this, leaving CreatePen() overload taking wxGraphicsPenInfo
where the real pen construction takes place and implementing
wxGraphicsPen creation from wxPen in the common wxGraphicsContext code.
This is not 100% backwards-compatible as any code inheriting from
wxGraphicsRenderer and overriding its CreatePen() will now be broken,
however this should be extremely rare (there is no good reason to
inherit from this class in the user code) and result in compile errors
if it does happen.
The latest of those checks tested for w32 API 3.3, which is older than
MinGW 3.4 released which is more than 13 years old, so we can safely
drop them (let alone checks for prehistoric 0.5 w32 API).
This incidentally fixes compilation errors due to the use of
wxCHECK_W32API_VERSION() in wx/msw/winundef.h which was now (since
the changes of 8c572c0a77) included before
this macro was defined.
If neither wxCAL_SUNDAY_FIRST or wxCAL_MONDAY_FIRST was given, use
wxDateTime::GetFirstWeekDay() to automatically determine the preferred
day.
This changes the earlier default behaviour, which was to use Sunday
if not otherwise specified. However, the wxGTK native calendar control
ignored this behaviour anyway.
This function tries to determine the preferred first day of week to use in
calendars. The procedure for obtaining this information is highly
platform-dependent, and is not possible on all platforms; in that case
Sunday is used as the fallback value.
Implementations are included for MSW, OSX, and Linux.
Display "long help" text associated with the toolbar items in the status
bar of the parent frame even if the toolbar is not a direct child of the
frame.
Closes#17897.
This message now appears even in the (default) release builds as __WXDEBUG__
is always defined, so it needs to be at least somewhat understandable by
normal users, even if it remains primarily targeted at the developers.
Also remove __WXDEBUG__ checks in this function, this is a left-over from the
pre-3.0 debug mode.
In wxStdDialogButtonSizer, keyboard navigation order through the buttons
should be the same as the order they are positioned in the sizer regardless
of the order the were created or added to the sizer.
Closes#17940.
