Using a Checkbox in the header to select all checkboxes in the datatable

kevin1293909

I have implemented a checkbox into the first column of my header as well as each row and have set up a jQuery event that recognizes when the header checkbox is checked and then checks all of the rows. The only problem is for some reason it only checks the first 40 some rows. I am using scroller in my initialization of the datatables and am not sure if this is causing my problem or not. Anyone have any experience with this?

//here is my initialization

myTable = $('#tblLineItems').dataTable({

"scrollY":        "300px",

"jQueryUI":       true,

"responsive":     true,

"dom":            "tS",

"deferRender":    true,

"order":          [[1, "asc"]],

"bSortClasses":   false,

"aoColumnDefs":   [

                  {"bSortable": false, "aTargets": [0,10]}

                  ]

  });

// here is my jQuery event

   $("#main-check").change(function() {

if($(this).is(":checked")) {

    console.log("2");

    $('.check-row').attr("checked", true);

} else {

    console.log("1");

    $('.check-row').attr("checked", false);

}

    });

//here is the data that is going into each row for the first column

   addData.push('<td><input class="check-row" type="checkbox" id="'+lineId+'"/></td>');

kevin1293909

Also if I check the main box and then uncheck it and then attempt to check it again, it wont check any of the rows a second time, but is still console.log()'ing just like it should be.

Woldere

You could try

.prop('checked',true); instead of .attr('checked',true);

Before jQuery 1.6, the .attr() method sometimes took property values into account when retrieving some attributes, which could cause inconsistent behavior. As of jQuery 1.6, the .prop() method provides a way to explicitly retrieve property values, while .attr() retrieves attributes.

Don't know if that'll fix it, more likely it's a problem in datatables, but it's worth a try.

kevin1293909

Thanks for the advice, I had already looked into that and it actually gives the exact same result. I'm thinking it has something to do with how many rows it has to perform the action on and possibly rows being considered hidden because they are so far away from where I am looking.