The text control needs a few event loop iterations in order to layout
itself correctly, so give it up to 1 second to do it in order to avoid
spurious test failures that occurred if just a single call to wxYield()
were done (or, worse, none at all as it was the case before).
Also log the value returned by PositionToCoords() in case of test
failures.
While it is added implicitly when running all tests in the order, this
style wasn't used if just this test was ran using "-c PositionToCoords"
option.
Specify wxTE_MULTILINE in it explicitly to allow this to work too.
Change this method to consider the coordinates corresponding to the last
position (i.e. the one beyond the last text character) as valid, for
consistency with wxMSW and to conform to the documented behaviour.
Also give more information about the failures in the corresponding unit
test to make debugging problems with this function simpler.
This is similar to e74fb5effe for wxMSW
and ensures that we don't consider the last position on the first line
invalid in wxGTK neither.
This fixes TextCtrlTestCase::XYToPositionSingleLine() unit test failure.
This was broken by 1c946a469a and resulted
in test failures in OwnerDrawnComboBoxTestCase::TextChangeEvents() unit
test because wxOwnerDrawnComboBox::Clear() used SetValue("") and didn't
generate any events any more.
Fix this regression by explicitly sending an event if we're returning
early and add a unit test explicitly checking that SetValue("") does
generate an event.
The variables and helper TempStringAssign class were added in order to
implement this, but somehow it was never done, so wxGetCurrentTestName()
always returned an empty string.
Fix this and so store the class/method name of the currently running
test in the global variables to give more context, notably for GTK+
errors.
It doesn't really add anything and it's more convenient to specify the
section on the command line (using the "-c" option) if it's just a
single word, without spaces, as it doesn't need to be quoted then.
The warnings are justified as the functions defined by the event table
macros are indeed not used here because we only write them to test that
they compile, but not useful, so suppress them.
wxUIActionSimulator is just too unreliable to be used there, so while
fixing it should really be a priority, for now at least prevent these
spurious failures from masking any other ones, which indicate real
problems that need to be fixed.
Notice that these tests can still be enabled by setting the environment
variable WX_UI_TESTS to 1 (or disabled by setting it to 0 under MSW).
Ensure we don't leave "mytext.dat" and "test.txt" lying around in any
directory the tests are run from by ensuring that these files are
destroyed by the test code using them.
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).
Check for web extension in ".." and "../.." to find it when running the
webview test and sample, respectively, even if "make install" hadn't
been done yet.
Also give a warning about the missing extension if we can't find it
anywhere.
While it is not guaranteed in general that destroying a window from an
event handler for an event originating from this window itself works, it
did use to work in the case of wxToolBar and its event handlers. However
this stopped working since faffaaae29 as
it added a test using the now deleted object member fields after the
call to the event handler.
To fix this regression without reintroducing the bug fixed by that
commit (see #16762), add an ugly way to check if the toolbar is still
alive after a call to its event handler and do it explicitly after
OnLeftClick() returns.
Closes#17732.
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.
Instead of adding a separate build, just reuse the existing monolithic
build to also use UTF-8: this is unlikely to miss any problems with the
monolithic build that would be found without using these options, but
also gives us a chance to find the problems in UTF-8 build, both at
compile-time and in the test suite.
Avoid the optimized mb_str() available in this build returning directly
a "char*" as it doesn't preserve the length of the string if it contains
NULs. Use mb_str(wxMBConv) overload instead which always returns the
buffer of the correct length.
Arguably, this is a problem of wxString API and maybe this optimized
mb_str() overload shouldn't be provided at all. OTOH the main reason for
wxUSE_UTF8_LOCALE_ONLY existence is optimization, so it seems a pity to
deliberately make the code less efficient when using it.
The wxGTK implementation uses wx{File,Dir}Button, which derives from
wxButton, but is not a GtkButton, so many operations which try to modify
it, such as changing it's style, are likely to result in errors.
See #17984
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.
This is necessary to properly upgrade the package dependencies when
installing the new versions of the packages themselves and fixes the
problem with the new Python 2.7.14 failing to run since its package was
updated from 2.7.13.
This doesn't work any longer since Cygwin Python 2.7.14 update, see
https://cygwin.com/ml/cygwin/2017-11/msg00053.html
Avoid using it by preventing include/wx/stc/stc.h file from being
updated, this shouldn't be necessary anyhow as the version in git should
be already up-to-date.
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.
