Switch from using just "bool expandSelection" in the grid functions
(possibly) extending the current selection to using the full
wxKeyboardState.
This allows to pass it to ExtendOrCreateCurrentBlock() and slightly
simplify the code by using DoMoveCursorFromKeyboard().
Don't try to extend the existing selected blocks to rows/columns, this
contradicts the documented behaviour which is to discard the selected
blocks that become invalid in the new mode.
Do handle switching to wxGridSelectRowsOrColumns mode, as there doesn't
seem to be any reason not to.
Update the tests to check for the expected selection update behaviour.
Change the return type of this function to a simple and clear bool
instead of 3-valued int requiring a special explanation. This is simpler
and not any less efficient as checking for whether one block contains
another or the other one contains this one are separate operations
anyhow.
Rename the function to a more grammatically correct name.
Also move it inline as it's now trivial enough for this to be worth it.
This class was a strange hybrid of a container/view/range and iterator,
as it both provided begin()/end() container-like methods and
iterator-like methods for dereferencing/advancing.
Simplify this by removing the latter part and making this class really
just a range, with its own iterator class in order to avoid leaking the
exact type of the iterator used in the API.
Note that while it's now completely trivial, it is still useful as it
isolates the application code from the vector used to store the selected
blocks currently and will allow to change internal representation in the
future without breaking the existing code.
Really edit the current selection block instead of storing the temporary
information about the current selection and applying it on releasing Shift
key or LKM.
VZ: [...] this is not used by wxGrid itself and SendEvent() is not part
of the public API, so we never made any promises about being able to call
it with wxEVT_GRID_RANGE_SELECT.
Store all types of selection with an array of blocks instead of arrays of
cells, blocks, rows and columns.
It (hopefully) simplifies the code and allows us to implement editing of
the last selection block much easier.
Line height calculation based on the font size is not right for wxGTK3
because native buttons (used as in-line editor buttons) don't scale down
well and they are not displayed properly within the line.
Minimal button size when the label is displayed properly is 35 so this
has to be minimal line height under wxGTK3.
Closes#18715.
For the sake of consistency with editor buttons created with
wxPropertyGrid::GenerateEditorButton(), the borders around the buttons
should be taken into account while positioning the buttons
in wxPGMultiButton.
Check that creating a wxTextCtrl doesn't generate any events to verify
that this problem doesn't exist in other ports, after fixing it in
wxGTK in 3e7e7dd24c (Avoid generating wxEVT_TEXT when wxTextCtrl initial
value is not empty, 2020-04-01).
Because the size of the text (usually) shown in the grid changes, the
size of its columns/rows should change as well when DPI changes. Scale
them by the DPI ratio if necessary, i.e. if any of them were set to
non-default values to achieve this.
Note that this is not ideal because it can result in rounding errors and
hence in slight change of row/column size when moving the grid window to
another display with a different DPI and then back, but to prevent this
from happening we'd need to store the column/rows sizes in DIPs inside
wxGrid and convert them to actual physical pixels everywhere, which
would require much more changes. Still, if the round trip problems turn
out to be a real problem in practice, we probably will need to do this.
Also note that this doesn't take care of the grid with a native header,
but this will be addressed by upcoming commits.
This handler redoes wxGrid layout and refreshes it to at least avoid
ugly display artifacts when moving wxGrid window between displays with
different DPI.
Since the changes in a40acbb28e (Add CanOverflow function to
wxGridCellAttr, 2020-02-06), cells with non-default vertical alignment
didn't overflow any more, even if their horizontal alignment was
unchanged and still defaulted to left-aligned.
This was due to assuming that if the alignment of wxGridCellAttr itself
was different from wxALIGN_LEFT, it meant that it wasn't left-aligned,
which seems logical but is in fact false, as the alignment can also be
wxALIGN_INVALID, in which case the real alignment is taken from the
default grid attribute.
Fix this by using GetNonDefaultAlignment() to get the alignment value
effectively used and add a unit test, as well as an example in the
sample, showing that this now works correctly.
