FixedHeader + Multiple Tables + Pagination = Wrong Headers Displayed

Ted T

Hi there ! I cannot find this listed in the forum, my apologies if I'm blind.

Thanks,
Ted.

Link to test case: https://live.datatables.net/zeyaduvu/1/

Debugger code (debug.datatables.net): awavad

Error messages shown: none

Description of problem: Multiple tables are on the page, both with fixed headers. Both tables have pagination enabled.
When you change the pagination of "Table A" (for example, increasing it from the default "Show 10 entries" to "Show 100 entries") and start scrolling, the fixedheader from "Table B" will be displayed momentarily.

allan

Interesting one! So the issue is that FixedHeader is using the positions that it calculates when it starts up - so table B is kicking in, when the scrolling hits the point that it would have before the page length was changed on the first table.

What needs to happen is that the positions get recalculated when the page length is changed.

table.on('draw', function () {
  table.fixedHeader.adjust();
});

Could be used for that: https://live.datatables.net/zeyaduvu/3/edit .

I'll have a think about how I might include that in the library to have it happen automatically.

Allan

Ted T

Awesome, Allan !

You have given me enough to work around the issue in my own project, but I thought I'd add a bit more of a spin on this particular curveball.

I modified your fix ; see https://live.datatables.net/guqalomu/1/

• I gave each table its own unique id.
• I modified the javascript to initialize each table independently.

The spin on the curveball is that when I change the page length for tableA , the "on draw" for tableA has to run tableB.fixedHeader.adjust() .

Thanks,
Ted.

_Edit: which implies if I have 10 tables with fixed headers on my page, then "on draw" for tableA has to run ( tableB ... tableJ ).fixedHeader.adjust() _

Ted T

Edit # 2

Spinning like a top...

See https://live.datatables.net/kitidopi/1/

If the position of tableA or tableB changes (for example, I dynamically added DOM elements above tableA -- not touching the actual data tables themselves), then FixedHeaders need to be adjusted.

No "fix" required for me, just food for your thinking process.

Thanks again!
Ted.

allan

Yeah. I'm not sure what the right thing to do is, other than have the developer a
Call the measure method when the DOM has been updated. I don't plan to have a mutation event listen on the DOM, but that is probably what would be needed.

Allan