Pagination resets to first page after editing a row with SearchPane filter active

Edus001

Hello,
I've run into a problem with Editor and SearchPanes. I've noticed that when I have a SearchPane filter selected (so only a subset of rows is showing) and I edit a row, the table redraws as expected but the pagination resets back to page 1. Without any filters, the table always stays on the same page after an edit.
I've tried to create an example showing the problem but I've run into some issues with live.datatables.net, and I'm thinking about the possibility that what I've described is the expected behavior of DataTables.
I'm using a table with data loaded from an Ajax source with client-side processing, and I'm capturing Editor's preSubmit event to update my database when a row is changed.
If this is expected behavior, it there any way to avoid it? I'll try to provide any additional information as needed.
Thanks in advance.

allan

Hi,

I've just tried to recreate the issue in this example but it seems to be working as expected.

If I edit a bunch of the rows to have 14 at the same site (to allow the paging test), then filter the table by tha site, jump to page two and edit a row, it stays on that page.

I'm wondering if you might be using an old version of the software?

Allan

Edus001

I'm using the latest DataTables, Editor and SearchPanes packages (from npmjs.com). The example works, however I'm using client-side processing, not server-side. If it's any help, I'm logging a message to console whenever the draw event is triggered and after editing a row I'm seeing that it's being called one additional time for each filter that is selected (for example, normally I see two messages, and if I select two filters it'll come up four times). Let me know if there's anything I can do to further debug the problem.

Edus001

I've made some breakthroughs. I've added the drawType: "none" option to the inline editor:

editor.inline(this, { onBlur: "submit", drawType: "none" });

This stopped all draw calls from DataTables, fixing the problem. However, without them the panes wouldn't update when a value was added or removed. For this, I had to manually call searchPanes.rebuildPane() when editing a row, and this caused the problem to reappear.

I've noticed that in the example provided the panes don't update, so maybe that's why it can't be reproduced there? Edit a name: the new value won't show up on the pane, and the former value will remain.