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
The .js file was created with hot-builder.
The following plugins were included/excluded:
AutoColumnSize [included]
AutoRowSize [included]
Autofill [included]
ColumnSorting [excluded]
Comments [excluded]
ContextMenu [included]
CopyPaste [included]
CustomBorders [excluded]
DragToScroll [included]
ManualColumnFreeze [included]
└── Included dependency: ManualColumnMove
ManualColumnMove [included]
ManualColumnResize [included]
ManualRowMove [included]
ManualRowResize [included]
MergeCells [included]
MultipleSelectionHandles [included]
ObserveChanges [excluded]
PersistentState [excluded]
Search [included]
TouchScroll [excluded]
UndoRedo [excluded]
We also only use the handsontable.css to excluded styles for the
unused pickaday datepicker. This should also prevent the problem from
issue #131.
The handsontable.css has also be created in the above mentioned process
and misses the styles for the excluded comment plugin
This makes the link-wizard usable again.
It changes the handsontable.full.js, since this seems to be the only way
to get the full functionality of the link-wizard. (As suggested by
@lisps)
However the trade-of is, that we may have to redo this when we update
handsontable.
An alternative approach which does not change handsontable.full.js, but
aborts the cell-edit-session is implemented in
12251b3e6cb62bdb1b8f4ccb43169c6cfaf7eae7
WIKI-156, fixes#32
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.
