[GH #9536] Cell contents in hidden row are affecting row height when using autorowsize

Tags: #<Tag:0x00007f8b2b7b8118> #<Tag:0x00007f8b1d48ff80>
#1

This is a follow on from my colleague Gareth’s earlier query in: https://forum.handsontable.com/t/row-heights-leave-lots-of-whitespace-in-cells/6649

The contents of a cell in a hidden column are affecting the row height when using autorowsize. The original solution was just to set a custom row height, but that is no longer an option. We need to use autorowsize - how do we fix this?

See: https://jsfiddle.net/markallenwebdeveloper/7kgtzhpq/11/ (hidden column 8 seems to be the source of the problem)

See also what happens if the hidden cell is empty: https://jsfiddle.net/markallenwebdeveloper/kfjrum98/3/

#2

Hi @woody

Thank you for contacting us. Unfortunately, this is a bug caused by wrong autoRowSize plugin calculations of strings divided with space, we have this issue reported here: https://github.com/handsontable/handsontable/issues/9536

#3

Thanks Adrian. It’s very disappointing that it’s been known about for so long and not fixed.

#4

For anybody struggling with this - I found a decent workaround…

I created a function called calculateRowHeight() which looks at the values in my data that are giving us problems. In our case, these are text fields that can accept a wide range of values/information from the user. Combined with autorowsize and column freezing, overflows can cause misalignment of rows, making the sheet unusable. calculateRowHeight() looks at these fields for all rows and returns a value in px to be used as the height for all rows.

In the Handsontable initialisation I use rowHeights(visualRowIndex) which is used to set row height on the initial render and on a re-render…

rowHeights(visualRowIndex) {
    let rowHeightToUse = calculateRowHeight(data);
    return rowHeightToUse;
},

…so, each time a change is made, the function runs and a new value set. Obviously, you can make this function as complicated as you need.

This does add a processing cost, but for a table of 1000+ rows it appears to be instantaneous. In our case anyway, changes to the data are a low volume event, so a small processing overhead is not a problem.

1 Like
#5

Hi @woody

Thank you a lot for the update and provided solution. We really appreciate your input, and I believe it will be helpful for other users until we implement the fix on our side.

1 Like