Grid cells are considered for redrawing solely based on having
a (text) value. This can lead to infinite recursion with overflowing
inside cells if wxGridCellStringRenderer::Draw() wants to draw cells
appearing after this one but instead visits the same cell again (because
of a negative cell size as opposed to expected default cell size of 1x1
or a larger spanning size) and calls DrawCell() again for this cell
which will call the renderer's Draw() again etc...
Fix by not taking inside cells into consideration for redrawing. This
is the right thing to do as earlier on in the same function a cell is
not drawn for the same reason. Also the aforementioned Draw() mentions
it shouldn't be called for cell sizes <= 0.
Also fixes the crashing grid test just introduced in 6d3dbc3fe5.
Use more appropriate colours for the row/column cell headers and don't
hardcode black (i.e. at least use white instead in dark mode) for the
frozen border.
Closes https://github.com/wxWidgets/wxWidgets/pull/2026
See #18941.
This fixes a bug due to a typo in ab02d36e10 (Account for vertical
alignment in wxGetGridCheckBoxRect() too, 2019-11-22) which used the
vertical component of a wrong object and so didn't actually offset the
checkbox by its size from the bottom of the cell rectangle, as it should
have done.
Closes#18907.
Simplify the code of wxGrid::DoGridCellLeftDown() and make it more
correct by using m_cursorMode instead of duplicating (not 100%
correctly) the logic used to set it in DoGridMouseMoveEvent().
If the assumption that m_cursorMode is already set by the time
DoGridCellLeftDown() is called turns out to be wrong, e.g. when wxGrid
is used on touch screens, we would need to refactor these functions to
extract the code determining m_cursorMode from the mouse location into a
separate function that would be called from both.
Note that this commit is best viewed with "git diff -w" to see how little
has really changed.
Generalize the changes of 415f080c80 (Split wxGrid RANGE_SELECT event
into SELECTING and SELECTED, 2020-07-27) to the case when the mouse is
dragged over row or column headers: also send SELECTING events while
dragging and a SELECTED event at the end, whether it's due to releasing
the mouse button or losing mouse capture.
Change the logic in ChangeCursorMode() to explicitly exclude the modes
for which the mouse should not be captured, as CaptureMouse() should be
called in most cases (and ideally for all of them in the future) and do
capture it for WXGRID_CURSOR_SELECT_{ROW,COL} too, if only to be
notified about mouse capture loss.
Remove m_isSelecting and StartSelecting() from wxGridSelection to avoid
inconsistency of wxGridSelection selecting mode state with wxGrid state,
as wxGrid already has m_isDragging field which tells it if the selection
state is final or not.
Instead, just allow wxGrid to specify the event to send from
ExtendCurrentBlock().
We still need a separate EndSelecting() for sending the final
wxEVT_GRID_RANGE_SELECTED event, but send it only for the last selection
block, and not all the selected blocks, as this makes more sense (there
should be one SELECTED event for each block and it was already sent for
the other blocks before) and is consistent with the events generated
when performing the same actions from keyboard.
This will allow the applications that are only interested in the final
selection to ignore the intermediate SELECTING events, which are now
sent as soon as the selection changes while dragging the mouse, and only
handle the final SELECTED ones, when the drag is over.
Don't bother trying to refresh areas beyond the visible part of the
window: not only it's useless, but it also results in debug warnings
from Cairo/pixman due to the use of negative rectangle width/height.
Closes#18848.
This simplifies the code by removing the need for a special event,
and also means the combox popup handler is no longer needed to reset
the inSetFocus flag for the closing handler.
The changes in 15de1a4cf4 (Optimize refresh when resizing grid rows or
columns, 2020-02-18) incorrectly translated XToPos() used in
SetRowSize() to YToRow(), which compiled due to an implicit conversion
of m_gridWin pointer to bool, but did the wrong thing, as the wrong grid
window could be used for a frozen grid.
Fix this by switching to internalYToRow() which actually does what the
original code tried to do.
Co-authored-by: Artur Wieczorek <artwik@wp.pl>
No real changes, just be consistent: as we have internalYToRow() macro
which passes true as "clipToMinMax" YToRow() parameter instead of the
default false, use it everywhere instead of using it almost everywhere
and still using YToRow(true) and XToCol(true) explicitly just once each.
Also add a comment explaining the difference between internalAToB() and
public AToB() functions.
Even when wxEVT_GRID_CELL_CHANGED is really vetoed, it's still possible
that m_currentCellCoords was changed by the handler, so use the row/col
coordinates of the cell that was really changed instead of the possibly
different m_currentCellCoords value to avoid a bug similar to the one
fixed by the previous commit.
The changes of e6e6dbe077 (Fix problems due to deleting grid cells in
the event handlers, 2020-05-02) fixed the bug (see #18731), but
introduced another one in place: if wxEVT_GRID_CELL_CHANGED handler
deleted any cells, wxGrid code could mistakenly restore the "old" cell
value (actually it restored the value for a different cell, as the
current cell coordinates necessarily changed too in this case).
This bug became more visible after the addition of activatable editors
as the new code asserts, instead of trying to restore the old value, if
wxEVT_GRID_CELL_CHANGED is vetoed, which also resulted in asserts if the
handler deleted the current cell instead.
Fix this by separating the cases of event being really vetoed and of the
event handler deleting the cell for which the event was generated and
handle the latter separately from the former where it matters.
This commit is best viewed ignoring whitespace changes.
This is more verbose, but also much more clear (and so allows to remove
some previously necessary comments).
No real changes, even keep the same values for the enum elements as were
previously used: this is probably unnecessary but do it just to minimize
changes.
This is useful for editors which don't really need to show any control
as they can change their value directly and will be used to reimplement
wxGridCellBoolEditor in the upcoming commits.
It was unexpected that pressing Shift-Enter while an editor was active
didn't close it, but just selected the cell below (and then the one
below it if pressed again and so on), so now always finish editing when
it's pressed.
It could be argued that it's still unexpected for Shift-Enter to select
the cell below after closing the editor, but this is consistent with how
Tab works, and so shouldn't be as confusing as the old behaviour.
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.
