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 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 makes it much more convenient to use interactively, as the cell
value is toggled immediately and, even more importantly, the UI doesn't
enter the confusing editing mode which doesn't look any different from
the normal grid appearance except for the current cell border absence.
Note that we still keep support for classic in-place editing to preserve
compatibility with the code which calls EnableCellEditControl()
explicitly and expects an editor to be shown, but perhaps we could
switch to using only activation in the future.
Add a helper class making it easier to define activation-only editors
and use it to implement MyGridStarEditor in the sample, showing a
typical example of using such editor.
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.
No real changes, just factor out code for getting and setting the grid
cell value as bool from {Begin,Apply}Edit() to {Get,Set}GridValue() to
make it possible to reuse these functions in the upcoming commits.
This commit is best viewed with the --color-moved option.
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.
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.
Apply the utility from https://github.com/codespell-project/codespell/
to fix spelling issues in the headers under both include and interface
directories and add a file with a couple of exceptions.
The exact command line used was:
$ codespell -w -I misc/scripts/codespell.ignore -i 3 in*
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.
Define the common logic for positioning editors not taking the entire
cell area (i.e. basically anything other than wxGridCellTextEditor) in
the new DoPositionEditor() function.
Also use the cell and editor alignment to decide where to position the
control if it's smaller than the cell, as it looks better if e.g.
wxGridCellDateEditor appears near the place where the date is displayed
instead of being centered in the middle of a wide column.
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.
GetPaths/GetFilenames() must be used instead when more than one file
could be selected: document this and assert if the wrong functions are
called.
Closes https://github.com/wxWidgets/wxWidgets/pull/1883
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.
Optimize wxGrid::AutoSizeColumns() for big grids.
This includes an optimization of wxDC::GetTextExtent() at the price of
slightly reduced precision in wxMSW.
See https://github.com/wxWidgets/wxWidgets/pull/1893
This allows to make computing the best width of numeric columns an O(1)
operation instead of O(number-of-rows), which can make a huge difference
for big grids.
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.
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().
For native wxGTK implementation default spin control precision is derived
from the precision of the increment value. Fot the sake of consistency the
same should be done in the generic implementation.
Closes#18764.
