We already had WX_ASSERT_EVENT_OCCURS_IN macro and a recent commit also
added code doing almost the same thing manually in wxTopLevelWindow unit
test, which was one version too many.
Replace both of them with the new EventCounter::WaitEvent().
No real changes, this is just a refactoring.
Account for the minimum and maximum dates supported by QDatePicker, both
in the code and in the test suite, which shouldn't rely on not having
any range restrictions in wxQt.
Closes https://github.com/wxWidgets/wxWidgets/pull/1088
Introduce wxQtEdit class and wxQtMultiLineEdit and wxQtSingleLineEdit
derived classes instead of using ifs in many wxTextCtrl methods, making
the code more clear and maintainable.
Also fix some wxTextCtrl-related unit test failures with wxQt and
disable some other ones which still don't pass.
Closes https://github.com/wxWidgets/wxWidgets/pull/1039
Compute the best size of the notebook, taking into account all the
different layout possibilities, and add a test checking that this works
as expected.
Closes https://github.com/wxWidgets/wxWidgets/pull/1085
Add test checking that selection is reset when deleting the selected
item or any item before, but not after, it.
Also explicitly document this behaviour.
This makes it possible to run the tests for all controls implementing
wxItemContainer interface by just passing "[item-container]" on the test
command line.
Fix the test added in dfec7aa0c0 which
deleted the button pointer used by EventCounter by simply moving
EventCounter initialization after the button re-creation.
See #16385.
Disabling a window before actually creating it ought to work, similarly
to hiding a window before creating it which can be used to avoid showing
the window on screen at all, even briefly. However it didn't under MSW
where the window was disabled from wxWidgets point of view, but not at
the MSW level.
Fix this by accounting for the enabled state in MSWGetStyle().
Closes#16385.
In wxMSW, the value of the control was modified after executing the
user-defined wxEVT_SPINCTRL handler which meant that any calls to
SetValue() there were effectively ignored.
Fix this and add a unit test checking for the described scenario.
Closes https://github.com/wxWidgets/wxWidgets/pull/1027Closes#18187.
For some unfathomable reason IsExpanded() returns wrong value for one of
the items. This should be fixed, but for now just leave a warning in the
test but don't fail it.
Also document this bug to at least spare people some surprises.
A couple of fixes compared to the previous commit:
- Use the correct gtk_tree_view_get_cell_area() rather than
gtk_tree_view_get_background_area() which doesn't work correctly
for the items which are not shown because their parent is collapsed.
- Translate logical coordinates to physical ones using
gtk_tree_view_convert_bin_window_to_widget_coords().
With these fixes, the unit tests for this function pass and can now be
enabled under wxGTK as well.
See https://github.com/wxWidgets/wxWidgets/pull/990
This was already the case if the item was not visible because its parent
was not expanded, but now make it also true for the items which are not
visible due to the current scrollbar position.
Add unit tests checking for this and also verifying that GetItemRect()
returns the coordinates in the physical window coordinates.
Replace a redundant (because the same size was already specified in the
ctor) SetSize() call with a Layout() call which resizes
wxDataViewMainWindow to fit the parent control size when using the
generic implementation.
This is important for any tests dealing with the control geometry, i.e.
calling GetItemRect() or HitTest().
Calling GetItemRect() for an item which was not currently visible
because its parent was collapsed resulted in silently returning the
value for a wrong value before the recent fix to GetRowByItem() and in
a crash after it because GetTreeNodeByRow() returned null when passed
invalid row index.
Fix this by explicitly checking whether the item is shown and just
returning an empty rectangle instead.
Also document this behaviour and add a unit test for it.
ChangeValue() must not send events, but did in wxGTK when changing the
contents of a wxTextCtrl to be empty when it had been non-empty before.
Closes#18264.
Comment stated that InsertionPoint() didn't pass, but it was actually
already running (and passing) and the only excluded test was the
TextChangeEvents() one which really should pass for multiline controls
as well, so run it too.
wxTreebook is supposed to allow not specifying any valid window for the
top-level pages, but this didn't work any longer, probably since the
changes of 02a92e23f3 (see #4379), as a
possibly null page was dereferenced without checking, resulting in a
crash.
Fix this by adding a missing check.
Also rename DoGetNonNullPage() to TryGetNonNullPage() to make it more
clear that this function can return null and add a unit test checking
that calling AddPage(NULL) really works (or at least doesn't crash).
See https://github.com/wxWidgets/wxWidgets/pull/921
This seems to be the case under all still supported MSW versions, so
remove the note saying that the events might not be sent from the
documentation and add a unit test verifying that they are indeed sent.
Contrary to what the documentation stated previously, this function does
generate the wxEVT_TREE_DELETE_ITEM events for all the items being
deleted, in both MSW and generic implementations.
Update the documentation and add a new unit test checking that the
behaviour really conforms to it.
Note that the control needs to be created with a reasonable size for
HitTest() to work correctly (at least under MSW, but probably not only),
so change the test set up function to use some fixed size for all kinds
of controls instead of doing it only for the multi-line ones.
These events are unexpected and inconsistent with the other platforms,
including GTK+ 2, so make sure we don't send them during the
destruction.
Closes https://github.com/wxWidgets/wxWidgets/pull/821
Escape backslashes in wxJSScriptWrapper to allow strings with
backslashes in them to work again -- this was broken while implementing
support for returning values from JavaScript to C++.
See https://github.com/wxWidgets/wxWidgets/pull/741
This reverts commit 1dd102d741 as it
introduced a crash in the same method when using generic wxDataViewCtrl
implementation, e.g. under MSW, and is not necessary to avoid the crash
with wxGTK3 any longer after the few previous commits.
GTK+ 3 (but not the generic version nor even GTK+ 2, apparently) sends
"selection changed" event from gtk_tree_model_row_deleted() when
deleting the currently selected row, which resulted in sending of
wxEVT_TREELIST_SELECTION_CHANGED events with invalid wxTreeListItem,
containing a dangling pointer, and a crash in the treelist sample when
trying to dump it.
Avoid this by clearing the model (and hence generating these events)
first and deleting the items only afterwards.
Also add a trivial unit test for wxTreeListCtrl::DeleteAllItems(), which
doesn't even allow to reproduce this bug, but is still probably better
to have than not to.
Closes#18045.
This test seems to consistently fail, but the failure can't be
reproduced locally nor debugged on buildbot, so, lacking any other
solution, just disable it.
The text and background colours are now stored in the rgba array instead
of fg_color and bg_color as with GTK+ 2 (the latter ones seem to have
been repurposed for the underline and strike-through colours!).
Also make the unit test for this method more robust.
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.