Check that all our public headers compile with this macro defined and
that using a char string without specifying its expected encoding
results in the expected compilation failure in this case.
Make Get[MultiLine]TextExtent() behave consistently for empty strings on
all platforms, in particular return (0, 0) size for them from
GetTextExtent() in wxGTK, which is an incompatible change but is needed
to make it behave in the same way as the others.
See https://github.com/wxWidgets/wxWidgets/pull/1970
This restores the previous behaviour inadvertently changed by bfeae1922d
(Minor optimizations in GetMultiLineTextExtent(), 2020-06-10) and makes
it official by documenting it and adding tests checking for it.
It wasn't completely obviously if this was intentional or accidental
before, but at least wxStaticText itself relied on the old behaviour,
and chances are that so did some code outside the library, so make this
part of the API now.
See #18825.
This seems more logical and is compatible with wxDC in wxMSW and wxGTK2,
as well as other kinds of DC, e.g. wxPostScriptDC.
It also looks like the current behaviour was unintentional as it
happened only because wxGCDCImpl::DoGetTextExtent() always passed all
non-null parameters to wxGraphicsContext::GetTextExtent(), even if it
didn't need the values for all of them, and thus bypassed the special
case for the empty string which was already present in the latter
function.
Fix this, making DoGetTextExtent() more efficient as a side effect (we
now avoid unnecessary calls to pango_layout_iter_get_baseline() in the
most common case), and also add another test for empty string to
wxGraphicsContext itself, for non-GTK case.
Also document this behaviour and add a test checking for it.
Using "x" as separator between the components created confusion with
hexadecimal notation, resulting in confusing messages like "0x17==0x0"
that seemed to describe comparison of 2 numbers and not 2 wxSize
objects.
Using "*" is also more consistent with wxRect output format.
Allow building without wxMenuBar (but with wxMenu), as this class
doesn't exist and can't be reasonably implemented under iOS (but
wxMenu can and should be, as it's widely used in iOS 14 UI).
This is embarrassing, but the iterator returned by this method seems to
have always been wrong, ever since it was added back in 946954d3bf
(Added reverse iterator to wxVector<T>, 2008-09-16). Moreover, it was
also broken in its const_reverse_iterator counterpart where it was
copy-and-pasted in f7ef20685f (Add wxVector<>::const_reverse_iterator,
2013-05-08).
Finally fix this to return the correct value and add at least a simple
unit test check that this method behaves as expected.
This is consistent with wxToString(wxColour) and seems more useful than
either returning black string representation (as wxMSW used to do) or
asserting (as wxGTK did).
Document this behaviour and add a test checking for it.
Closes#18623.
Also define wxColour-specific matchers to allow comparing RGB(A)
channels to the expected values, replacing the old ASSERT_EQUAL_RGB(A)
macros.
No real changes.
Add a new string fragment type for whitespace and punctuation which needs
to be assessed separately from letters and symbols.
Use wxUint64 instead of long for storing the value for numeric fragment.
Use collate instead of compare for non-numeric fragments.
Change names for the public comparison functions: wxWidgets provided function
is now named wxCmpGenericNatural() and for common public use is wxCmpNatural()
which calls a native function in wxMSW and wxCmpGenericNatural() elsewhere.
Try harder in wxCmpNaturalGeneric() if wxRegEx is unavailable: do not
just make a simple string comparison, but perform a case-insensitive
collation.
Make some other changes to simplify and possibly speed up the code.
Replace manual calls to setlocale() with the existing helper class.
This makes the code slightly simpler and avoids -Wnoexcept-type warnings
due to using setlocale as template argument as a welcome side effect.
If wxSizerItem passed to Replace() contains a window, the window must be
associated with the sizer to ensure that it is uncoupled from it when it
is destroyed.
Add a simple test which resulted in a use-after-free before but passes
now.
The sizer item allocated by wxSizer::Add() was leaked if an exception
was thrown due to the use of invalid flags, resulting in tons of memory
leak reports from the leak sanitizer.
Fix them by using wxScopedPtr<> for this item and releasing it only if
adding the item to the sizer (unexpectedly) did not throw.
No real changes.
Optimize wxGrid::AutoSizeColumns() for big grids.
This includes an optimization of wxDC::GetTextExtent() at the price of
slightly reduced precision in wxMSW.
See https://github.com/wxWidgets/wxWidgets/pull/1893
Handle the case of a single line string specially, it's faster to do
this than use slow loop over all characters.
Also avoid constructing the string with the characters to measure one by
one and do it all at once instead.
Add a possibility to benchmark GetMultiLineTextExtent() rather than
GetTextExtent() in the graphics benchmark.
These functions are much simpler to use in the application code using
wxGrid in row- or column-only selection mode than GetSelectedBlocks()
itself because they take care of deduplicating, ordering and squashing
together the adjacent ranges, so that the application can use their
results directly, unlike with GetSelectedBlocks().
The "unique" rows/columns arrays used in the implementation of these
functions were not unique at all, as we happily added duplicates of the
existing items into them. Fix this by checking that a row/column is not
already present before adding it.
Add a (previously failing) unit test checking that this works correctly
with overlapping selected blocks.
