Completely overhauled selection handling in wxGrid.
Make various ways of extending selection (using Shift-arrow keys,
Ctrl-Shift-arrows, Shift-click etc) work as expected from the user point
of view instead of producing various bizarre results. Also improve
row/column header click selection as well as Ctrl/Shift-Space handling.
Internally, store selection as just a vector of blocks, independently of
the selection mode, and provide a simple API for iterating over it which
remains usable even with selections containing millions of cells (as
long as they're still composed of only a few blocks, which is the case
in practice).
Add more tests and add display of the current selection to the sample.
See https://github.com/wxWidgets/wxWidgets/pull/1772
A libinotify compatibility library exists for BSD systems. If this
was installed, configure would find sys/inotify.h but the build
would fail to link unless the library was added to the link line.
By also checking for inotify_init() this problem can be avoided.
Given that there is native support for kqueue, there is no need
to handle linking with libinotify.
Extend the existing selection instead of adding a new block, as there is
no reason to keep the old selection as a separate block, when it's
always a subblock of the new one, and doing it resulted in wrong
behaviour when selecting 2 horizontally adjacent cells, pressing
Ctrl-Space and then pressing Shift-Left deselected the rightmost
selected column but still left its single cell, which was part of the
originally selected block, selected, which was surprising and looked
wrong.
Restore IsFocusable() check that was commented out, without any real
explanation, by c7bfb76a2c (A number of focus handling improvements:
Left clicking on a window only focuses the window if not processed.
wxControlContainer::SetFocus moved to wxControlContainerBase so that a
container now focuses the first child even on wxGTK. wxAuiBook is now a
container, need for correct navigation on wxGTK., 2007-08-18).
This is needed to avoid giving focus on click to the windows that
explicitly override AcceptsFocus() to return false, as e.g.
wxGridColLabelWindow and other wxGrid subwindow classes do. From the
user point of view, previously clicking on a grid row/column label just
disabled the user of arrow keys, which was very inconvenient (and didn't
happen under MSW).
Put linker flags determined by configure after -L$(LIBDIRNAME) option
pointing to the directory containing the libraries being built, to
ensure that we link with these libraries rather than any wx libraries
globally installed in the system, as could be the case since the changes
of ec091c9f2b (Don't override CFLAGS etc in configure-generated
makefile, 2020-02-02).
See #18729.
Don't hardcode black colour, it results in unreadable text when the
theme uses dark background. Note that this was already done under Mac,
but this commit does it under all platforms.
Also improve the contrast of various other colours when using
non-default background, this notably drastically improves readability of
the button labels when using the standard MSW "high contrast" mode.
Closes https://github.com/wxWidgets/wxWidgets/pull/1791
Don't blankly forbid selecting any blocks at all in this mode, this
didn't really make any sense.
Moreover, SelectBlock() not doing anything prevented wxGrid code
handling {Ctrl,Shift}-Space from doing anything in this mode and, worse,
broke the logic of DeselectBlock() which relied on using SelectBlock()
to select the remaining parts of the selection, so this commit fixes
using Ctrl-click for deselecting rows or columns in this selection mode,
which was previously completely broken.
No real changes, just make the code more clear by always explicitly
selecting either wxHORIZONTAL or wxVERTICAL instead of default for the
former for no good reason (by symmetry, it is not a better choice than
wxVERTICAL).
Also list all wxGridSelection enum elements in the switch over selection
mode to avoid warnings about not handling wxGridSelectRows.
Unselected current cell should always be considered as the current
selection block to extend, as it doesn't make sense to extend any other
block (perhaps selected on another side of the grid) when pressing
Shift-arrow.
This scenario could be achieved by selecting a block and Ctrl-clicking a
cell (either inside or outside the selection) twice and then extending
it using Shift-arrow keys. Previously, this behaved in a strange way,
combining the corner of the selected block with the target of the
movement, whereas now this just starts selecting a new block from the
current cell as expected.
Use wxGridSelection::IsInSelection() instead of GetSelectedRows/Cols()
which can be much slower as they need to produce an array containing
indices of all the selected rows/columns.
Don't extend the selection if the anchor line is not selected, as this
doesn't work correctly because the entire selection logic supposes the
anchor itself is selected and, moreover, it's not really clear how could
it would otherwise.
This commit does the same thing for rows/columns as the grandparent
commit did to the cells. Unfortunately a somewhat cleaner solution of
the parent commit can't be easily applied to the existing rows/columns
code and it's arguably not worth changing it in depth just for this.
This commit doesn't change the behaviour compared to the previous one,
but provides an alternative implementation of the same goal, which seems
preferable: instead of not extending the selection while Ctrl-dragging,
just don't enter dragging mode, i.e. don't capture the mouse and don't
set m_isDragging to true, if we start it from a previously selected, and
hence currently deselected, cell.
Property bitmap should be stored in its original size and rescaling
to the required size should be done only while drawing the property.
This way bitmap size will always fit to the actual wxPG line height.
Dragging in a grid with Ctrl key pressed starting from a previously
selected cell behaved very counterintuitively if not downright wrongly,
as the selection logic assumes that the selection anchor itself is
always selected, which wasn't true in this case.
Solve the problem by just not extending the selection at all when
starting to drag from a deselected cell. This means that Ctrl-dragging
doesn't do anything any more, but it's not a huge loss and to make it
work well while still allowing to use Ctrl-click to toggle the cell
selection, we'd need to implement a whole new and different
drag-deselect mode, as is done in Microsoft Excel 2016 (note that the
previous versions of Excel don't implement Ctrl-dragging neither).
Remove the "performDefault" variable which didn't really seem to help,
as the actual meaning of the return value is whether we should start
drag-selecting or not and the name of this variable didn't reflect this
anyhow.
Return false if we are over an invalid cell: this shouldn't change
anything when we're already dragging, but would prevent us from starting
to drag from an invalid cell which seems more correct, even if it's not
clear if this can happen in practice.
Also move hiding the edit control inside "isFirstDrag" check, there is
no reason to do it on every drag.
This is not necessary any longer as the current cell is changed on
Ctrl-click since the previous commit.
This commit is best viewed ignoring whitespace.
There isn't really any valid reason to ever set the current cell to the
corner of a block remaining after breaking up the currently selected
block after the deselection of the just clicked cell, so don't do it.
Just set the current cell to the clicked cell, whether it's selected or
not.
This is more consistent with Ctrl-clicking cells.
It also slightly improves behaviour when Ctrl-dragging mouse over the
range of selected lines, although it's still somewhat surprising.
Scroll the new end of selection into view only vertically, it would be
unexpected for the vertical Page Up/Down movement to scroll the grid
horizontally.
Update the cells that had to be deselected due to the selection mode
change.
This used to work, but the refresh was lost during a previous
refactoring.
Also make Page Up/Down themselves work consistently with the other
cursor movement keys and clear current selection if they move the
cursor.
Even though DoMoveCursorByPage() is simpler than DoMoveCursorByBlock(),
still factor out AdvanceByPage() for consistency with AdvanceByBlock()
and because it still makes the code more clear.
Extending the selection with Ctrl-arrows is different from all the other
cases, as we need to combine both the selection anchor and the current
cell coordinates when doing it.
This means that we can't reuse the same PrepareForSelectionExpansion()
helper for this case, so this function is not useful finally and this
commit removes it entirely. It also replaces GetCurrentBlockCornerRow()
and GetCurrentBlockCornerCol() functions with GetExtensionAnchor() which
combines both of them.
Finally, it adds wxGridDirectionOperations::TryToAdvance() helper to
avoid repeating the IsAtBoundary() check which was previously part of
PrepareForSelectionExpansion() in multiple places.
And because the "extending" and normal parts of DoMoveCursorByBlock()
are so different now, it also factors out AdvanceByBlock() helper which
can be used to keep these parts well separate from each other instead of
intermixing them together.
With all these preparatory changes, it's finally possible to implement
the "extending selection by block" logic relatively easily, with the
bulk of this branch actually taken by comments explaining why do we have
to do what we do.
Add unit tests verifying that the functions used by Shift-Ctrl-arrow
work as expected.
The selBlock reference could be used after the vector invalidation,
which resulted in using the wrong vector element at best and could
probably lead to a crash at worst.
Don't use it after invalidating the vector any longer.
This notably fixes a bug in row-or-column selection mode where the grid
wasn't updated visually after modifying its selection by deselecting a
single cell as soon as there were more than one selected row or column.
Mouse events in row/column headers should be just ignored when the
current selection mode disallows row/column selection.
This wasn't the case before, and while actually selecting the line
corresponding to the header was disallowed further down the call chain,
clicking it still unexpectedly cleared the existing selection and
dragging mouse in the header window selected the entire grid.
Fix this by just never entering the corresponding cursor mode in the
first place if it's incompatible with the current selection mode.
This function finally doesn't ever create a new block, except for the
trivial case when there is no current block, so rename it to a simpler
and more clear name.
No real changes.
