This test just doesn't want to work when run on GitHub CI under wxGTK2
even though it works perfectly locally. So enable the test at least for
all other ports.
A generic multi-select wxListCtrl did not deselect a single selected
item that did not have focus when the user single-selected another
item.
This fixes a regression introduced in fedc80eee3 (Improve selection and
focus events generation in wxGenericLisCtrl, 2020-10-10).
Closes#24312.
It seems that WebKitGTK is now failing to navigate to about: URLs unless
they are about:blank or about:srcdoc, so use about:srcdoc as the
alternate URL to fix the WebView tests.
Ref: 3c3163e71f
For some completely mysterious reason we don't get the expected mouse
click events when running under AppVeyor, something might be covering
the window and stealing the clicks for itself there.
As there doesn't seem to be anything to do about it, just skip the test
in this case.
Closes#24082.
Try making this test more robust as well as it also sporadically fails
on AppVeyor.
Also simplify it a bit, checking for each of the expected events in turn
instead of checking for their total number at the end.
This test doesn't use the native header but somehow still fails on
AppVeyor and locally a very failure can be reproduced if the mouse is
moved while the test runs, so check for this here too.
Not sure if it really helps, but try to wait for the events in these
tests as well if only for consistency with what was done in 3d07de66b1
(Add a wait to wxGrid UI unit tests too, 2023-10-03).
Qt uses QString::localeAwareCompare() for comparison and this is what their
documentation says: "On other Unix-like systems without ICU, the comparison
falls back to the system library's strcoll()". Under MSW, Qt uses CompareStringEx()
IOW, Qt always compares strings by locale-specific sorting criteria and BTW
this is what wxGTK was like before this commit 625ed74 (Make sorting of wxListBox,
wxChoice and wxComboBox identical to the MSW sorting)
The wxListCtrl would assert with this message: '../src/qt/listctrl.cpp(452):
assert "col < columnCount()" failed in SetItem(): Invalid col'
Because under wxQt: no columns means no items, and no items means
no selection can be made at all.
Wait for a bit before checking for the expected event as a single
wxYield() call might apparently not be enough under load, as this test
sporadically fails in AppVeyor CI builds even though it passes locally.
This test sporadically fails under AppVeyor, perhaps due to a hard-coded
sleep in it which may somehow misbehave there -- try changing it not to
rely on this sleep.
This has a nice side effect of making the test run faster, too.
Previously it only inherited from wxTextEntryBase in the generic
implementation (used e.g. in wxMSW).
Update the code, documentation and add new unit tests checking that
wxSearchCtrl member functions inherited from wxTextEntry behave
correctly.
Closes#23686.
Closes#23697.
Clear the cached attributes when replacing the table they were used
with.
Add unit test checking that the attributes are not used any longer.
Closes#23607.
This doesn't work due to LM_GETITEM not returning the expected result
after changing the state using LM_SETITEM under Wine.
It could be worked around by remembering whether we changed the colours
in our own variable, or maybe just reverted later if Wine fixes this,
but for now disable the test.
This isn't supported by the native control, and it doesn't seem worth to
make an extra effort to support it, so just document it and stop
checking that it works in the unit test.
This partially undoes the changes of bc23b1f4f0 (Use wxBaseArray instead
of object array for wxAuiToolBarItemArray, 2023-04-11) as they broke the
existing code using wxAuiToolBar because the pointers to the tools were
not stable any more.
At least avoid the use of the ugly -WX_DECLARE_USER_EXPORTED_OBJARRAY()
macro by just using wxBaseObjectArray<> directly, which is simpler now,
after the change in the parent commit.
Add a trivial test checking that pointers to wxAuiToolBar tools remain
stable when more tools are added.
Closes#23514.
For some reason, calling HasSelection() immediately after SelectAll()
causes the web extension to get stuck under WebKit 2.40. Instead of
sleeping, call wxYield() a few times to let the event loop run a bit.
