Searchpanes: Is there an event for when searchpanes are finished building?
Searchpanes: Is there an event for when searchpanes are finished building?

Link to test case:
Debugger code (debug.datatables.net):
Error messages shown:
Description of problem: I am trying to rebuild some graphs when search.dt is fired. However, I see that search.dt is fired every single time EACH searchpane is getting built. I also noticed that initComplete on the datatable happens BEFORE the searchpanes are created. Is there a separate event that fires when the searchpanes are done being created?
This discussion has been closed.
Answers
Each SearchPane is a Datatable. You can use the
searchPanes.dtOpts
orcolumns.searchPanes.dtOpts
to define aninitComplete
function that runs when the SearchPane init is complete. IS this what you are looking for? If no please provide details of what you are trying to do with the graphs.Kevin
@kthorngren That's very useful to know, and I will keep that in mind!
I think I was thinking more in terms of when ALL the searchpanes are complete. For example, I notice that there is a block that says "Loading Search Pane" on initialization and then disappears when the searchpanes are complete. I'm assuming that there is some event that destroys that block once ALL the searchpanes are complete.
Looking at the SearchPanes docs I don't see a section for
events
.I'm guessing the problem you are seeing is shown in this example:
http://live.datatables.net/cukizoqa/1/edit
This is an ajax loaded Datatables and the
search
event is triggered during Datatable initialization. In this example it shows the DatatablesinitComplete
runs after all the SeachPanesinitComplete
. Are you seeing or doing something different in your code?One option might be to create the
search
event handler ininitComplete
Kevin
That's so interesting - that is correct, this code that you posted is working differently than my code. In my code, the searchpanes are building AFTER initComplete by the table, and I'm not sure why. TO give more clarity, I am using the following searchpane options:
cascadePanes: True
columns: [various]
panes: [various]
layout: 'columns-1'
I have no idea why searchpanes would initialize after initComplete. Any ideas?
I'm fine with search.dt running while searchpanes are building since I can bind the event i'm trying to run to search.dt AFTER searchpanes are built.
However, the main problem is trying to figure out why initComplete happens BEFORE the searchpanes are built. This is very strange.
Are you initializing SearchPanes using the API like this example?
Are you using server side processing?
The developers may be able to say why without seeing your code. But we may need a test case or at least a posting of your Datatables init code.
Kevin
If possible, I'd like to keep my code confidential but I'm more than happy to provide certain snippets that aren't too revealing in terms of data.
Are you initializing SearchPanes using the API like this example? No
Are you using server side processing? Yes >> Interesting question! How does server side impact the initialization process?
I haven't used it myself but you might be interested in the SearchPanes Server Side Processing docs. Not sure if this is causing the difference in the event order.
Kevin
Oh you know what, I lied... I am simply getting data using ajax, but it's one time and not necessarily server side. All processing is still on client side.
However, maybe getting data using the ajax property might be what's causing it different behavior?
My example uses the
ajax
option.Did you try using
initComplete
in thesearchPanes.dtOpts
like my example to see when they fire? Maybe you can update my example to show the issue.I'm out out of ideas. The developers may have some input for you.
Kevin
@kthorngren thanks for all your help! I figured out my issue. I'm not sure why, but a JS file imported from https://cdn.datatables.net/searchpanes/1.1.1/js/dataTables.searchPanes.min.js was somehow causing the issue. I instead downloaded a nightly build of searchpane and used that instead and now it works =/ not sure why that would be.