Handsontable always applies the "move" operation to the supplied data
array, hence we always denied the move operation for handsontable and
instead update it with a moved data array.
I'm not sure why the `target += 1` was introduced, but it caused wrong
behavior which was fixed by removing it.
Moving a row, changes the object the `meta` variable points to. However
the context-menu got its own reference to the initial object when it
was initialized. Hence after a move, these two were out of sync. By
providing getters to the context menu, it should always have access to
the object the current meta variable is referencing.
In the beginning handsontable_config.data is set to the object in the
data variable. However if that data variable is assigned a new object,
then these two are out of sync.
This results in errors, for example the deletion of a row would than no
longer remove that row from the data variable (only from
handsontable_config.data, which is a different object).
APL-60
This is mostly indentation and double->single quotes. It includes
turning qunit env on for qunit test-files and disabling no-magic-numbers
for a test-file that is all about moving a row from position one to
position two and back again.
One can no longer select individual rows/cols that are part of a merge.
Thus one cannot delete rows/cols that are part of a merge but only all
rows connected to the merge.
Please note that it is important to use `undefined` as the second
argument in the alter() function instead of `null`. See
handsontable/handsontable#4458 for the bug tracking ticket at upstream
Now we recalculate the merged Cells from the meta array after every move
and update the settings with these new values, even if potentially
nothing changed.
While this may cause an (insignificant) performance hit, it is much
simpler code than any alternative of figuring out if merges were affected
and how they changed by a move.
It is an undocumented feature of the beforeColMove Callback, that
returning false prevents the move.
ToDo
----
* Maybe we want to show a message informing the user that moving
cols/rows into merges is not allowed
The definition for the callback function for `beforeRowMove` and
`beforeColumnMove` has changed to allow for the simultaneous move of
multiple rows/columns
Currently the default width of a cell is wide enough to support its
entire content. Add the config option to specify a default width for all
columns. This may make sense since for cells with very wide content the
cell may become wider than the screen.
ABY-67
This is a workaround to rerender the table. It serves two functions:
1: On wide tables with linebreaks in columns with no pre-defined table widths
(via the tablelayout plugin) reset the width of the table columns to what is
needed by its no narrower content
2: On table with some rows fixed at the top, ensure that the content of these
rows stays at the top as well, not only the lefthand rownumbers
Attaching this to the event 'afterRenderer' did not have the desired results,
as it seemed not to work for usecase 1 at all and for usecase 2 only with a
delay.
Free as in - has no pre-defined width
When setting colWidths instead of manualColumnResize then the
auto-resizing would break. This affected both columns without a
predefined width and the resizing by double-click.
Handontable stores the information which colmuns have been moved where
in an internal-ish. This internal state can be explicitly set by the
manualColumnMove or manualRowMove option. (see official handsontable
documentation).
We therefore reset this state its default values and directly apply the
meved rows/columns to the data-array.
