Dyanmically changing height of data table does not maintain "scrollCollapse=yes" setting.

Dyanmically changing height of data table does not maintain "scrollCollapse=yes" setting.

mdorsamdorsa Posts: 14Questions: 2Answers: 0

Hi, I'm having a problem getting the following (essential) feature to work with the latest DataTables (v1.10.13). This feature has worked fine for us in all DataTables versions up to and including our latest, which is v1.10.5.

The problem is that when dynamically changing the height of a data table on a browser resize event, the "scrolllCollapse=true" setting is not maintained, and the data table displays empty rows to fill the specified height.

Here is the problem live (note that you must resize the browser to see the problem):
http://live.datatables.net/begahafe/1/edit

Note that for DataTables v1.10.5 (old APIs), the following resize code worked properly (the old "bScrollCollapse=true" setting was maintained during the resize):

var oSettings = dataTable.fnSettings();
oSettings.oScroll.sY = <new height>;
dataTable.fnDraw();

I'm looking forward to upgrading to the latest DataTables version (v1.10.13), but we will have to stay at v1.10.5 if there is no solution for this issue, as this feature is essential for our UI.

Thank you!
Marc

This question has an accepted answers - jump to answer

Answers

  • kthorngrenkthorngren Posts: 21,568Questions: 26Answers: 4,996
    edited January 2017

    Made the following change to your example's window.onresize function:
    Changed: $('.dataTables_scrollBody:has(#example)').height(height + "px");
    To: $('#example_wrapper .dataTables_scrollBody').css("height",height+"px").css("max-height",height+"px");

    Using DT 1.10.13 the table seems to resize correctly. Checkout your updated example:
    http://live.datatables.net/begahafe/2/edit

    EDIT: It doesn't fix your problem. Added records to test. With fewer records the scrolllCollapse still doesn't work.

    Kevin

  • mdorsamdorsa Posts: 14Questions: 2Answers: 0

    Thanks for trying Kevin, but yeah, the problem still exists.

  • allanallan Posts: 63,844Questions: 1Answers: 10,518 Site admin
    edited January 2017

    I'm afraid I'm not getting it. If you want the scrollCollapse to be maintained, why set the height of the scrolling container to something else?

    http://live.datatables.net/begahafe/3/edit - without setting the height of the scrolling container.

    One thing that you might be interested in - have you seen this page?

    Allan

  • mdorsamdorsa Posts: 14Questions: 2Answers: 0
    edited January 2017

    Hi Allan,

    (As I'm sure you know,) the scrollCollapse (=true) setting keeps the height of the table no taller than necessary to display the rows. Without this setting (=false), and as you can see in my example (when increasing the browser height), the table's height will extend beyond what is necessary when there are less rows than needed to fill the requested height. This is visually unacceptable to me for a professional UI and would look to our users like a mistake or a bug.

    I will look at the page/link on Vertical Page Fitting you posted above, but note that that example does not use a scrolling table.

    So, is there a way with 1.10.13 to do what I can easily do with 1.10.5?

    Thanks,
    Marc

  • mdorsamdorsa Posts: 14Questions: 2Answers: 0

    Hi Allan,

    Looking at https://datatables.net/blog/2015-04-10, this won't work for us because it requires "paging=true", and we don't use paging (only scrolling). It also requires that, "Every row must be of equal height", which is not the case in our UI.

    Marc

  • allanallan Posts: 63,844Questions: 1Answers: 10,518 Site admin

    HI Marc,

    I'm really sorry - I'm being utterly thick. But, if you want the behaviour of scrollCollapse, why is some of your external code changing the height of the scrolling container?

    I don't quite get why you are changing the height of the container? Or are you saying that the scrollCollapse doesn't work in 1.10.13 (which it does appear to for me).

    Can you show me an example of the behaviour you are looking for with 1.10.5 please?

    Allan

    p.s. In my defence, its first thing on a Monday morning :smile:.

  • mdorsamdorsa Posts: 14Questions: 2Answers: 0
    edited January 2017

    Hi Alan,

    Yes I totally understand Monday mornings. :)

    Here is the example (with correct behavior) you requested:

    http://live.datatables.net/kuxanuqe/1/edit

    This (correct) behavior works with DataTables up to and including v1.10.7.

    • The table's height is dynamically changed to fit within the browser's height (up to a point). This allows the OK/Cancel buttons, along with any other essential controls located below the table, to remain visible & accessible even when the page/browser height is decreased.

    • The table's height is automatically clipped (via DataTables' "bScrollCollapse=true" setting) when the total row height is less than the requested table height.
      This is the feature that I cannot get to work with DataTables v1.10.8 or later.

    Thank you,
    Marc

  • allanallan Posts: 63,844Questions: 1Answers: 10,518 Site admin
    Answer ✓

    I'm with you now! Thanks for the example :smile:.

    Here is how it can be done with 1.10.8 and newer (this example uses 1.10.13): http://live.datatables.net/kuxanuqe/2/edit .

    Basically I changed DataTables to use max-height rather than height for the scrolling container. Since there is no public API to change the scrolling container height in DataTables (settings.oScroll.sY in the private parameters) it never needs to be applied again, which is why the draw had no effect.

    Using jQuery to update the CSS property does the trick.

    Allan

  • mdorsamdorsa Posts: 14Questions: 2Answers: 0

    Thank you Allan...works great! B)

    Marc

This discussion has been closed.