I've a simple setup as follows:
A master table (DummyMaster in the demo a virtual 1 row only table)
Two (potentially) different sized details next to each other (DetailLeft and DetailRight) within that master.
Below a footer is placed to test.
The master expands as expected keeping the footer intact.
However grouped regions and hidden rows below the master are not shiftet alongside.
I'd have expected them to stay consistently to the footer.
Test.zip (15.3 KB)
Sadly this is a known limitation of this approach, and there is not much that can be done to avoid it. It happens whenever you insert a range of cells instead of full columns.
Imagine we have something like this:
Note that row 10 is still taller, but row 14 is not. In an ideal world, cell D14 would be taller, and D10 would not, but that's not possible with a grid like the one in Excel. You can have either the full row taller or not, but not one cell of the row taller.
When FlexCel balances the bands, it will now insert cells in the rest of the columns so the row is moved down:
The yellow row will go down, but the row 10 will still be bigger, not row 14. This is because every time we insert cells, we aren't moving the full row, so the row doesn't move. We end up moving all the cells down, but the row didn't move. Something similar happens with merged cells: if when you insert some cells down you break a merged cell, and then insert cells to move the rest of the merged cell down, the cell won't remerge after it is moved.
The way to avoid this kind of stuff is to insert full rows, not parts of the rows. The workaround here is to join DetailLeft and DetailRight into one single dataset (you can use FlexCel's join or just do it in SQL: Join and Union (Delphi) | FlexCel Studio for VCL and FireMonkey documentation )
Then you just use a single __detail__ range that will move the full row down, and avoid breaking stuff when inserting only parts of the row
