There hopefully isn't any reason preventing us from using dotted pens 20
years after the commit 00e12320ca (Some debug code. Removed flicker form
wxTreeCtrl. Changes.txt update., 1999-12-22) disabling them because they
were "too slow under XFree86" was made.
Fix issues with FreeBSD build: use just built, instead of already
installed, libraries (this one is not really FreeBSD specific) and use
kqueue even if sys/inotify.h is available but inotify itself isn't (at
least without linking with an extra library).
Closes#18729.
These methods do the same thing, so it seems better to use the same name
for them.
This is not really a backwards-incompatible change, as these methods
were just added in the parent commit, so nobody is using them yet.
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.
