Edge does not support the about: URL using it in the test resulted
in various problems. Just use about:blank for now as the edge backend
does not merge them for the history checks.
These functions used to work in any mode until the changes of 02509cbc39
(Refactor wxGridSelection to store selection as blocks only, 2020-03-03)
and should continue to do so, if only for compatibility.
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.
Do this for consistency with the other ports and because this seems more
useful anyhow.
Update the documentation to make this behaviour more clear and document
this change as a (minor) incompatibility in wxMSW.
Also add more unit tests to check for this behaviour. Note this also
fixes the problem with the unit test added in the grandparent commit
under MSW.
Just return NULL from this (wxOSX private, in spite of not using a
port-specific prefix) method.
This fixes crash in wxButton::SetBitmapXXX(wxNullBitmap), as shown by
the new test case which used to crash but doesn't do it any longer.
Closes#19257.
Add wxUILocale class providing functionality which can be implemented
portably for all major platforms, including macOS, and doesn't force
the change of the global C locale, unlike wxLocale.
See https://github.com/wxWidgets/wxWidgets/pull/2464
It was already disabled under AppVeyor and it also fails when using
GitHub Actions.
This almost certainly indicates that there is a bug in our code, but as
the failure still can't be reproduced locally, it's difficult to debug
and fix, so for now just also disable the test when using GitHub CI.
The condition guarding wxEVT_TEXT_URL test was changed to use
wxHAS_2CHAR_NEWLINES in 15c5125572 (Refactoring, 2021-08-07) but
shouldn't have been as this has nothing to do with the use of "\r\n"
under MSW.
No real changes.
Under MSW creating a wxSpinCtrl with a range of, say, 1..10 and the
default initial value of 0 sets its initial value to 1 (i.e. the closest
valid value) as expected, but the generic version still set it to the
invalid value of 0, which was unexpected, inconsistent and not useful.
Fix the generic version to follow MSW behaviour now and add a test
checking for this.
This will allow using this class in the library code too.
No real changes yet, this is a pure refactoring.
This commit is best viewed using git --color-moved option.
Apparently setting focus doesn't work until a mouse click is simulated
to bring up the main test window to the front. This happened implicitly
when running the full test suite, due to e.g. doing it in wxButton unit
tests, which come before wxComboBox::ProcessEnter test, but not when
running just this test (or wxTextCtrl::ProcessEnter) on its own.
Make the test self-contained by simulating a mouse click before
simulating pressing "Enter".
This was broken in to 682cb8355c (Replace "sendEvent" parameter in
wxGridSelection with "eventType", 2020-08-21) which changed Select() to
take wxEventType argument but still passed it "true" in a few places.
Fix this and add a unit test verifying that this works as expected.
Ideal would, of course, be to avoid implicit conversions from bool to
wxEventType but making wxEventType anything other than int, for which
such conversions are unavoidable, is too backwards-incompatible to
seriously consider.
Otherwise wxDynamicCast-ing wxAuiNotebook to wxBookCtrlBase didn't work
(even if the more usual and useful upcast did still work).
Add a unit test for this.
There doesn't seem to be any reason to only forward CHAR events, but not
KEY_{DOWN,UP} ones, so do the same thing for the latter ones too.
This allows to get rid of GetMainWindow() call in wxDataViewCtrl unit
tests, as wxEVT_KEY_DOWN are now correctly received in the control
itself and not just its main window.
Using increment greater than 1 but with a fractional part should still
work, i.e. should use enough digits to fully show the fractional part of
the numbers that can be obtained by using this increment.
wxSpinCtrlDouble::SetIncrement() should increase the number of digits if
necessary because not doing it would be inconsistent with the initial
determination of the number of digits in the ctor and would actually
lose the digits displayed, but it seems unnecessary to decrease the
number of digits and it might be surprising, so don't do it.
Add a test for this behaviour and document it.
This is consistent with using the value of the increment specified in
the ctor for setting the initial number of digits, it was surprising
that creating the control with some value of the increment (e.g. 0.1)
and calling SetIncrement(0.1) later resulted in very different outcomes,
as in the former case the value was shown with a digit after the period
while in the latter case only the integer part was shown.
This also makes the behaviour compatible with that of the previous
versions of the generic wxSpinCtrlDouble, which used "%g" to format the
number before the changes of edc553870f (Fix displaying wxSpinCtrlDouble
values with default precision, 2020-05-18), as they did show the
fractional part even in the latter case.
Add a test checking that this works as expected: before this commit, the
test failed with "1 == 1.2" and "1 == 1.23" errors.
The function was documented to not generate the events, but actually
did generate wxEVT_TEXT ones, even if it didn't generate wxEVT_SPINCTRL.
This was inconsistent with wxGTK and generic wxSpinCtrlDouble used under
MSW, so change this to avoid the unwanted events.
Previously, wxSpinCtrl (using native control) and wxSpinCtrlDouble
(using the generic implementation) behaved differently in this case,
with the former changing its value but the latter keeping the last valid
value instead.
Make them behave the same by resetting the value in both cases and
document this behaviour.
Fix the bug introduced in the recent 34ab87ce4d (Get rid of CppUnit
boilerplate in wxSpinCtrlDouble unit test, 2021-04-19) which resulted in
failures in the subsequent unit tests and ensure that the spin control
is destroyed at the end of the test.
wxSpinCtrl::GetValue() behaviour after calling SetValue("") is currently
inconsistent between wxMSW and wxGTK, or even between wxSpinCtrl and
wxSpinCtrlDouble in wxMSW.
Disable the recently added test checking it for now.
Make it possible to use a string value different from the numeric value,
as wxMSW version allows this and some existing code depends on it.
Closes#19140.
Multicells currently don't get any special treatment when inserting
or deleting rows or columns so neither a multicell's main size nor
inside cells' sizes (which are offsets to the main cell) are updated.
Most tests fail and will be fixed by the next commit.
See #4238.
Do some simple sanity checks with attributes, particularly overwriting
a cell with NULL attribute (as was already checked very usefully in
the grid sample for ref count reasons), and their total count in a grid
when inserting and deleting rows and columns.
While the tests are not particularly useful for the next intended grid
change, they do contain some functions that also work for upcoming tests
so these (harmless) tests are included as well.
Somehow ASAN reports a memory leak in this test:
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fc54732ebc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x7fc546685cb8 in g_malloc ../../../glib/gmem.c:102
#2 0x7fc543a49b41 in _gtk_rbtree_new ../../../../gtk/gtkrbtree.c:333
#3 0x7fc543b0831a in gtk_tree_view_real_expand_row ../../../../gtk/gtktreeview.c:12922
#4 0x7fc543b1087a in gtk_tree_view_expand_row ../../../../gtk/gtktreeview.c:12983
#5 0x7fc5453ba344 in wxDataViewCtrl::DoExpand(wxDataViewItem const&, bool) src/gtk/dataview.cpp:5013
#6 0x7fc5458e5a0e in wxDataViewCtrlBase::ExpandAncestors(wxDataViewItem const&) src/common/datavcmn.cpp:1297
#7 0x7fc5453bce08 in wxDataViewCtrl::SetSelections(wxDataViewItemArray const&) src/gtk/dataview.cpp:5228
#8 0x5557834c5745 in test controls/dataviewctrltest.cpp:178
#9 0x5557834d688c in invoke ../3rdparty/catch/include/internal/catch_test_registry.hpp:25
#10 0x5557831434ef in Catch::TestCase::invoke() const ../3rdparty/catch/include/internal/catch_test_case_info.hpp:176
#11 0x55578317f10f in Catch::RunContext::invokeActiveTestCase() (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bc10f)
#12 0x55578317e9dd in Catch::RunContext::runCurrentTest(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bb9dd)
#13 0x55578317b5cc in Catch::RunContext::runTest(Catch::TestCase const&) (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1b85cc)
#14 0x55578313c64a in Catch::runTests(Catch::Ptr<Catch::Config> const&) ../3rdparty/catch/include/internal/../catch_session.hpp:82
#15 0x555783180e05 in Catch::Session::runInternal() (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bde05)
#16 0x555783180931 in Catch::Session::run() (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bd931)
#17 0x555783180899 in Catch::Session::run(int, char const* const*) (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bd899)
#18 0x55578315719a in TestApp::RunTests() test.cpp:635
#19 0x5557831a63c7 in TestApp::OnIdle(wxIdleEvent&) (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1e33c7)
#20 0x7fc5446bbbfe in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const src/common/appbase.cpp:654
#21 0x7fc5446bbdba in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const src/common/appbase.cpp:666
#22 0x7fc5449b29dd in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) src/common/event.cpp:1416
#23 0x7fc5449b47f4 in wxEvtHandler::SearchDynamicEventTable(wxEvent&) src/common/event.cpp:1888
#24 0x7fc5449b32be in wxEvtHandler::TryHereOnly(wxEvent&) src/common/event.cpp:1609
#25 0x7fc5449b70a7 in wxEvtHandler::TryBeforeAndHere(wxEvent&) include/wx/event.h:3949
#26 0x7fc5449b2f72 in wxEvtHandler::ProcessEventLocally(wxEvent&) src/common/event.cpp:1546
#27 0x7fc5449b2ec5 in wxEvtHandler::ProcessEvent(wxEvent&) src/common/event.cpp:1519
#28 0x555783156ef7 in TestApp::ProcessEvent(wxEvent&) test.cpp:615
#29 0x7fc5446badef in wxAppConsoleBase::ProcessIdle() src/common/appbase.cpp:431
but only if another wxDataViewCtrl test runs after it, i.e. there is no
leak when running just this test on its own.
This doesn't seem to make sense, as wxDataViewCtrl, and hence
GtkTreeView, is destroyed at the end of the test and it shouldn't be
possible for a test running later to affect the presence or absence of a
memory leak in it, so it might be a LeakSanitizer bug, but this doesn't
help actually getting rid of it.
The only other possibility would be to suppress this leak, but this
doesn't seem ideal, as we could suppress some other real leak too, so
for now just skip this test when using ASAN.
Don't return anything from it, just warn directly -- this is what all
the existing callers did, so it's simpler if the function just does it
itself instead of forcing them to check its return value.
Also reset m_painted after yielding, so that YieldUntilPainted() could
be called again, if necessary.
The actual cause of the problem was the tests making the single-line
text control height far too large. So just use the default height for
single-line controls.
The way the test grid is set up forces drawing of an inside cell (part
of a multicell) which shouldn't normally occur. In this case it
leads to an infinite recursion while drawing the inside cell. Drawing
of inside cells will be fixed by the next commit.
