Generic script error when using 1.10.15
Generic script error when using 1.10.15
redblue
Posts: 5Questions: 2Answers: 0
Hi,
I'm having a really odd error when using 1.10.15. I'm using a Web Browser control on Windows (IE 11) and Datatables is working well, until the container is resized, then the attached error happens.
As you can see, the error isn't very helpful:) Any idea's on how I should track this issue down?
Regards,
This discussion has been closed.
Answers
I've managed to get actual errors showing (using debug versions). The errors are in the function_fnCalculateColumnWidths and are "null" reference errors for headerCells[i]. I don't know why the errors happen, but hacking in basic fixes makes the errors go away and everything seems ok. Thoughts?
Changing this:
to:
and:
to:
In this case I wasn't sure of the right 'fix' so to speak.
Can you show me your DataTables configuration and also the HTML for your table please?
Thanks,
Allan
I've ran into this problem last week, I was using the Responsive plugin therefore resizing the window would cause datatables to recalculate the columns widths. I believe DataTables resizes all tables it holds in memory in this case, which makes sense, however, if you have removed the table from the DOM but not called
destroy
on the table you will get this error.So, if you have a datatable that is no longer in the DOM but DataTables still knows about it and expects it to be there you get this error. Perhaps a new technical note @allan ?
Have you removed tables from the DOM but not called
destroy
?I toyed with the idea of modifying DataTables to use the MutationObserver API to detect removal of the table from the DOM and automatically call
destroy
but opted to clean up after myself properly instead.Thanks for the replies @allan and @rduncecb . Yes, I'm using destroy, but the table isn't being removed from the DOM in all cases where this error crops up. HTML Code:
JS code:
The Datatable is being populated from a websocket connection so there is dynamic interaction, ie, the above html is created on the fly.
The
destroy
option isn't quite the same asdestroy()
. As @rduncecb says, it might be worth usingdestroy()
if the table already exists, and empty its contents (so only thetable
element is left).Allan
Ok, I've restructured the code to this:
With the first chunk of testing, the errors seem to go away. I'll play some more and see what happens.