performanceinfragisticshtml-tablewebdatagridoffsetwidth

Efficient way to measure longest cell in table column


I am trying to determine the widest content in HTML table cells of fixed width. Currently I am using an external sizer DIV:

 <div id="xdivSizer" style="position:absolute;display:inline;visibility:hidden">
 </div>

in this code

var iColWidth = 0;

for (var Y = 0; Y < oDataTable.rows.length; Y++) {
    oDivSizer.innerHTML = oDataTable.rows[Y].cells[0].innerHTML;
    iColWidth = Math.max(oDivSizer.offsetWidth, iColWidth)
}

It works, but extremally slow, even when the table has only 100 rows or so. It looks like main offender is calculating of offsetWidth. Is there a more efficient way to achieve this?

I am doing this because I need to resize that table column to the size of the widest data. If there're other better way, that would be great as well.

(More precisely I am trying to implement "column autosize" feature in Infragistics WebHierarchicalDataGrid control for ASP.NET - columns need to take the widest width Max(Header Width, Data Width) while maintaining fixed header/pager positions).

Thanks!


Solution

  • Rewriting the DIV contents will trigger copious redraws, applications of your CSS, DOM manipulations etc..

    Try putting all of the cells from the column in the DIV all at once, separated by line breaks -- or each in it's own sub-DIV. The width of the resulting DIV should be that of the longest cell.

    var html = [];
    for (var Y = 0; Y < oDataTable.rows.length; Y++) {
        html.push(oDataTable.rows[Y].cells[0].innerHTML);
    }
    
    oDivSizer.innerHTML = html.join("<br />");
    var iColWidth = Math.max(oDivSizer.offsetWidth, 1);
    

    Another possibility is a simple heuristic based on each cell's innerText.

    var iColWidth = 0;
    for (var Y = 0; Y < oDataTable.rows.length; Y++) {
        var w = Math.floor(oDataTable.rows[Y].cells[0].innerText.length * 11.5);
        iColWidth = Math.max(w, iColWidth);
    }
    

    And yet another possibility, as indicated in my last comment, is to redraw only the TD in the column that consumes the greatest area.

    var a = 0;
    var n = null;
    for (var Y = 0; Y < oDataTable.rows.length; Y++) {
        var _a = oDataTable.rows[Y].cells[0].offsetHeight * oDataTable.rows[Y].cells[0].offsetWidth;
        if (Number(_a) > a) {
          a = _a;
          n = oDataTable.rows[Y].cells[0];
        }
    }
    oDivSizer.innerHTML = n.innerHTML;
    var iColWidth = Math.max(oDivSizer.offsetWidth, 1);
    

    Or, taking it a step further, divide the calculated area of each cell by the number of BR's found to account for "intentionally" tall cells.

    var a = 0;
    var n = null;
    for (var Y = 0; Y < oDataTable.rows.length; Y++) {
        var _a = oDataTable.rows[Y].cells[0].offsetHeight * oDataTable.rows[Y].cells[0].offsetWidth;
        var brs = oDataTable.rows[Y].cells[0].getElementsByTagName('br');
        _a = Number(_a) / brs.length;
        if (_a > a) {
          a = _a;
          n = oDataTable.rows[Y].cells[0];
        }
    }
    oDivSizer.innerHTML = n.innerHTML;
    var iColWidth = Math.max(oDivSizer.offsetWidth, 1);
    

    But, as the complexity of the fuzzy approaches grows and the result becomes more accurate, you can expect performance to decline.

    As a side note, if this auto-sizing is being applied as the result of a user interaction, I'd suggest performing the sizing calculations / processes immediately after the table is available to be analyzed, rather than waiting for the user to initiate the resize.