The problem as seen by the user: if you have a table of 2 rows and 1 column,
and the separator line is dragged upwards by the mouse, then undo doesn't
restore the original situation.
Two items are created on the undo stack: sd::UndoGeoObject and
sdr::table::TableRowUndo. Let's say the table height is 8000 mm100 and the two
cell heights are 4000 and 4000. If the user resizes the first cell, so that its
height is 2000, then the new table height will be 6000. The problem is that
when undo is executed, first sd::UndoGeoObject resizes the table, distributing
the newly available 2000 between the existing rows, and then
sdr::table::TableRowUndo sets the row height of the first row: the height of
the second cell will be larger than expected. Fix the problem by not doing a
relayout during sd::UndoGeoObject, but doing a relayout after
sdr::table::TableRowUndo in this case.
This is done by:
1) Adding a new SdrDragStat::mbEndDragChangesLayout, so that
SdrTableObj::applySpecialDrag() can inform SdrDragObjOwn::EndSdrDrag() that
TableRowUndo will do the layout instead of UndoGeoObject. (This is done only in
case a row edge is dragged, as otherwise it's not guaranteed that a
TableRowUndo will follow the UndoGeoObject on the undo stack.)
2) Adding a new SdrUndoGeoObj::mbSkipChangeLayout, so that
SdrTableObj::applySpecialDrag() can let SdrUndoGeoObj::Undo() not do the
layout.
3) Adding a sdr::table::SdrTableObjImpl::mbSkipChangeLayout, so that
SdrUndoGeoObj::Undo() can let SdrTableObj::NbcSetLogicRect() not do the layout.
4) Marking the table model as modified in TableRowUndo::setData(), so it does
the layout at the end of the undo group.
Change-Id: I8adde3cdad5741e6fcb420e333ce336e18c77cf1
Reviewed-on: https://gerrit.libreoffice.org/24363
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
cafc53f8b4