Although this variable, and a check for it in OnKeyDown(), was present
since the first version of this code added back in f85afd4e46 (Added new
wxGrid classes[...], 1999-10-06), there doesn't seem to be any
indication that it has ever been needed, so remove it to simplify the
code and make it possible to add early returns to this function easily.
No real changes yet.
Since the changes done in 8b2237cd2d (Make row/column drag-resizing in
wxGrid "live", 2020-03-01) the grid editor was dismissed whenever the
mouse crossed any row/column separator, which was, of course, wrong, as
it was only supposed to be hidden when row/column was actually resized,
i.e. when the separator was dragged by the mouse.
Fix this by moving calls to DoStartResizeRowOrCol() to more appropriate
places and do it only when the button is pressed now.
Note that it might actually be better to just disable column/row
resizing while a cell is being edited, but for now keep things working
as they did before and at least fix the latest regression which is
definitely unwanted.
No real changes, just use the value returned by the function to
determine if the cell is inside a multi-cell, instead of comparing
rows/columns with 0 to make code slightly more readable and self
explanatory.
Checking the new function return value is simpler than checking the
value of m_cellEditCtrlEnabled after calling EnableCellEditControl().
Do this now also when starting editing using the mouse, as it was simply
forgotten before and so StartingClick() was still called even if editing
was vetoed.
Also add DoDisableCellEditControl(), but this one exists purely for the
symmetry.
This also allows to reset m_cellEditCtrlEnabled earlier, as we don't
have to keep it true for the duration of HideCellEditControl()
execution.
No real changes, as with the previous commit, this one is best viewed
ignoring whitespace changes.
It doesn't make sense to perform the checks in ShowCellEditControl()
when it's called from EnableCellEditControl() and this makes the code
unnecessarily fragile as m_cellEditCtrlEnabled needs to be set at just
the right moment for it to work correctly.
Call the new DoShowCellEditControl() instead and perform the checks only
in the public function, for compatibility.
Also note in a comment and the documentation that ShowCellEditControl()
is not very useful anyhow and that EnableCellEditControl() should most
often be used instead.
No real changes (the commit is best viewed ignoring whitespace changes).
This check was introduced back in 283b7808d8 (added support for readonly
cells and 3d border drawing, 2000-02-16), but was wrong even then and
remained wrong ever since: we must not set m_cellEditCtrlEnabled to true
when the current cell is read-only, so there is no need to check for the
latter condition if m_cellEditCtrlEnabled is indeed true.
Ensure that we really never erroneously set m_cellEditCtrlEnabled for
the read-only cells by replacing an wxASSERT_MSG checking for this in
EnableCellEditControl() with wxCHECK_RET().
Also explicitly document this function precondition, also added back in
b54ba67107 ([...] added CanEnableCellControl() and use it before calling
EnableEC, 2000-02-17) but never documented so far.
This code seems to have been there ever since da6af900f1 (Added
drag-shrinking, 2000-02-04), but while it probably made sense back then,
it lost its purpose a long time ago as the cell editor is now not only
hidden, but also disabled when drag-resizing starts, so it doesn't make
sense to attempt showing it back when the mouse button is released: it's
never going to do anything (and didn't).
Just remove this code, as hiding the editor while drag-resizing is not
the behaviour we want from the UI point of view anyhow. And, again,
removing it doesn't actually change anything in the current version of
the code.
This allows to fold the last DoSaveEditControlValue() call into this
function, so that it's only called from DoAcceptCellEditControl() or
from SaveEditControlValue() (which is public, and hence can't be
changed, even if its behaviour doesn't make much sense).
This commit means that m_cellEditCtrlEnabled is now reset to false when
AcceptCellEditControlIfShown() is called, which was not the case before,
but this seems to make sense, as we shouldn't be just hiding the editor
while leaving it enabled, and, also, doesn't really seem to change
anything as hiding the editor indirectly results in a call to
DisableCellEditControl(), via wxGrid::OnHideEditor(), and so it was
actually already reset before -- but now this happens slightly earlier
and more explicitly.
This is just another refactoring in order to avoid duplicating calls to
HideCellEditControl() and SaveEditControlValue() in several different
places.
Also call DoSaveEditControlValue() because if the editor is shown, it is
also necessarily enabled and there is no need to check for this.
No real changes, just simplify the code by using a single function to
retrieve the editor to use for the current cell.
This also allows to get rid of a few temporary variables, further
amplifying the simplification.
Pressing Esc while double clicking on the column separator in the native
header in wxGrid could result in a crash due to using invalid index when
calling GetColLeft(m_dragRowOrCol) in GetPositionForResizeEvent() called
from DoHeaderEndDragResizeCol() because m_dragRowOrCol had been already
reset to -1.
Guard against the crash with a check in GetPositionForResizeEvent()
itself and also add a check to DoHeaderDragResizeCol() to avoid calling
the former function in this case.
Reproducing the original problem is relatively simple as it's enough to
just keep double clicking a column separator while also pressing Esc,
but catching it under debugger is much more complicated and so it's not
really clear how exactly does this happen, but tracing shows that the
native control just decides to generate two HDN_ENDTRACK messages
without any intervening HDN_BEGINTRACK, so it doesn't seem like we can
do anything else than just silently ignore the unwanted HDN_ENDTRACK, as
it's done in this commit.
Even when resizing rows by dragging their edges was disabled via
DisableDragRowSize(), it was still possible to try to resize them when
the mouse was over the cell corner.
Fix this and remove the special case for the corners entirely, it's not
necessary as the existing cases cover this one already.
Just rearrange them in the right order to prefer column resizing, as
this seems to be a much more commonly used operation than row resizing.
It is necessary to do it since the switch to double buffering wxGrid
painting in ebbadae09a (Double buffer wxGridWindow drawing, 2020-01-28)
as even a "full cell" editor such as wxGridCellTextEditor still doesn't
fill the entire cell, as there are margins around it, and the backing
bitmap could keep whatever junk happened to be there if we didn't erase
it, so do erase it now.
Remove the code doing the same thing from ShowCellEditControl(),
however, as it's redundant and doesn't do anything except creating some
flicker, and also doesn't work on the platforms not supporting the use
of wxClientDC anyhow.
The existing logic for adjusting the editor window position by moving it
was flawed as it didn't take into account the fact that the editor could
decide to use a different (and usually bigger) rectangle than the one we
provided it with, if it doesn't fit into the given one. Fix it to ensure
that the editor window is fully inside the grid client area by moving it
only after letting it choose its own size.
The existing code was also inconsistent as CalcDimensions() didn't take
any adjustment to the cell rectangle done in ShowCellEditControl() into
account at all and always just blithely assumed it was positioned at the
cell top left corner, which resulted in wrong virtual size calculation
and could make scrollbars appear when starting editing, as happened in
the "Bugs table" example of the grid sample when showing any comboboxes
in the last grid row. Fix this code to use the actual editor rectangle
instead.
This is another attempt to get rid of the flicker when using the native
header control with wxGrid under MSW and avoid calling UpdateColumn(),
which is currently implemented in a very inefficient way in wxHeaderCtrl
under MSW, during interactive resizing.
See #18794.
Clicking on (or near) the grid column or row edges was handled specially
to allow dragging them in order to resize the column or row, but this
doesn't need to be done if drag-resizing the columns or rows is not
allowed in the first place and resulted in surprising user-visible
behaviour: e.g. when using row selection, clicking mostly anywhere in
the row selected it, except if the click happened to be between the two
columns, in which case it didn't.
Fix this and always select the row in such scenario now.
Unfortunately, doing this required adding yet more CanDragXXX()
functions in addition to the already impressive panoply of them in
wxGrid, but we need CanDragGridColEdges() as none of the existing
functions checked for m_useNativeHeader (there was instead an ad hoc
check for it directly in the mouse handling code) and the row version
had to be added for symmetry.
Previously columns using a set of predetermined values used plain
wxGridCellStringRenderer, which didn't allow to determine their best
size efficiently, as wxGrid had to iterate over all the rows of the
table, even if they only took a couple of possible values.
Add wxGridCellChoiceRenderer (refactoring wxGridCellEnumRenderer to
extract the common code from it in the process) which implements
GetMaxBestSize() by just finding the best size of all of these values,
which is much faster for large grids.
This does result in a change in behaviour, as the column now adapts to
its "theoretical" best size and not just the size of the values actually
shown in it, but this seems to be a worthwhile trade-off and could even
be seen as an advantage, as editing a cell won't make its value overflow
the auto-sized column width any more, as it is wide enough to show any
of the column values.
This is another optimization, useful for the renderers that are used
with the values of a fixed form or part of a limited set, as it is much
faster to compute the best size for all values of the set rather than
computing them for all the cells in the column.
Get rid of the unnecessarily complicated functions doing two quite
different things depending on whether their first boolean parameter was
true of false.
Instead, split their body between AutoSize{Columns,Rows}() (which used
to call them) and DoGetBestSize(), keeping just the part needed in each
case.
This is much simpler and even more efficient, as it avoids a completely
unnecessary call to CalcDimensions() and Refresh() from DoGetBestSize(),
which doesn't change the current size at all and so doesn't need to
refresh anything, but previously did it and not only once, but twice,
because both of SetOrCalc{Column,Row}Sizes() did it.
Remove needless subtraction of row/column label size before adding it
back again, as this seems completely unnecessary.
No real changes, this is just a simplification.
These functions are much simpler to use in the application code using
wxGrid in row- or column-only selection mode than GetSelectedBlocks()
itself because they take care of deduplicating, ordering and squashing
together the adjacent ranges, so that the application can use their
results directly, unlike with GetSelectedBlocks().
Use wxSYS_COLOUR_BTNFACE instead of the hardcoded value of this colour
in "Windows Classic" theme, which was probably used back when the commit
73145b0ed1 (Applied patches by Scott Pleiter:, 2002-12-09), which was
supposed to change wxGrid to use system colours (among other things),
was done.
Nowadays wxSYS_COLOUR_BTNFACE is 0xF0F0F0 rather than 0xC0C0C0, which is
quite different visually, but it still seems better to use the system
colour rather than the fixed value, especially for platforms with dark
mode support.
Closes https://github.com/wxWidgets/wxWidgets/pull/1866
Skip the key events other than Ctrl-C/Ins which are used for copying
grid contents to the clipboard, notably Alt-C which should still be
usable for opening the menus.
This fixes a problems introduced in 67c1c412c6 (Implement support for
copying wxGrid cells to clipboard, 2020-04-26), see #13562.
This is useful for read-only grids, in which an editor can't be shown to
copy the value of a cell, and also for copying an entire selection block
and not just a single cell.
Closes https://github.com/wxWidgets/wxWidgets/pull/1824Closes#13562.
Previously, pressing Enter in a cell of a row which wasn't the last one,
but was the last shown one, didn't do anything because we explicitly
checked whether the cell was in the last row and not in the last visible
row, but MoveCursorDown() doesn't move the cursor for the latter, and
not just for the former.
Fix this by avoiding any row checks at all and just calling
MoveCursorDown() in any case and DisableCellEditControl() if it didn't
do anything.
Closes#18754.
Deleting last grid rows or column in a few event handlers could result
in asserts/crashes in wxGrid code if the event handler also called
event.Skip(), as wxGrid still tried to perform the default action using
the deleted cell, when these events happened in the last row or column.
It's not totally clear whether calling event.Skip() after performing an
action modifying the grid should be allowed at all, but, in doubt, at
least avoid crashing if it does happen, by considering the event as
being handled (and even vetoed) if its handler deleted the cell in which
it was generated.
Closes#18731.
Move the logic determining the return value of SendEvent() into its own
function instead of repeating it twice.
No real changes, this is a pure refactoring.
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.
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.
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.
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.
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.
