On DC with a non-rotated coordinate system drawing a filled rectangle with ExtTextOut() Win API is faster than drawing a line with MoveTo()/LineTo() so on such DCs we can use ExtTextOut() to draw horizontal/vertical lines with solid colors and square ends instead of calling MoveTo()/LineTo().
See #18517.
This method is supposed to be overridden in the sub-windows of a
composite control (and is indeed correctly implemented in
wxGridSubwindow), but it doesn't make any sense to implement it in the
parent window itself.
This method was probably never executed (which is how the problem went
unnoticed for 10+ years since 760be3f7cb),
but it's still wrong to define it here, so remove it.
This is unnecessary as TAB navigation is not supposed to work between
wxGrid children and actually harmful as this resulted in SetFocus()
doing nothing, instead of setting focus to wxGridWindow, if the focus
was on wxGrid itself for some reason (this happened at least in the grid
unit tests and resulted in failures because the in-place editor didn't
appear as expected).
Somehow, mouse release events generated immediately after the mouse
press ones are sometimes (not always, but often enough to reliably
prevent the test suite from passing) simply lost, i.e. not received by
the GTK event loop.
The only workaround seems to be to introduce an artificial delay, which
does avoid the problem, at the price of making the tests run longer and,
worse, not really solving the underlying problem, whatever it is. But
it's still better than nothing.
Unbind the event handler referencing a local variable, as leaving it
bound could result in a crash later if another paint event was generated
for the window for whatever reason.
Doing it like this requires using 2 different objects, but the
complexity can be still hidden inside WaitForPaint class, with the 2nd
object being just a member of it, and, in fact, makes the code using it
simpler as it doesn't need to use a boolean variable with it.
Restore the checks for the model stamp, reverting the changes of
18594afe76: we still need to ignore the
calls to at least iter_children() and iter_nth_child() model methods
that can be called from inside gtk_tree_view_set_model() when we reset
the model, as running these methods crashes when trying to use the
pointers to already deleted items.
For consistency and robustness, add checks for the model stamp to all
the methods and not just those two, just in case other ones end up being
called later in some way.
Also add a unit test checking that DeleteAllItems() doesn't crash and
does delete all items.
Closes#18533.
The previous fix in 5442edbbe9 corrected
the type for the older NetBSD versions, but not NetBSD 10, which now
uses "void*", as all the other platforms, so restrict the original fix
to NetBSD versions < 10 only.
See #18199.
For some reason, names were used for cyan and light grey, even though
all the other ones used RGB values since refactoring the stock objects
to be created on demand in f516d98637.
Use RGB values for these two as well now.
Closes#18530.
This is an ugly workaround for a mysterious problem occurring with the
simulated "Enter" presses under GTK, but it's worth it, as it allows all
grid tests, including the ones using wxUIActionSimulator, to pass now
under wxGTK2 (a couple of tests still fail under wxGTK3).
For some reason, mouse press events were still received without
flushing, but mouse release ones were not received by GTK itself (and a
fortiori by wxGTK) without it.
This was sufficiently misleading that event our own wxGrid unit tests
used this function in an attempt to start editing a grid cell -- even
though it actually doesn't do it at all.
Unfortunately documenting the surprising semantics of this functions
looks like the best thing we can do because it appears to have always
behaved like this and changing it now to actually show the cell editor
control, i.e. starting to edit the cell, is almost certain to break some
existing code.
This makes simulating keys much more reliable, previously they were just
completely lost (i.e. never resulted in key-press-event signal being
generated by GTK) sometimes.
These tests are still disabled by default during run-time, but at least
allow explicitly enabling them (by setting WX_UI_TESTS=1) even when
using wxGTK where they're known to fail.
