Sort order difference between initial and later sorting

drumex

The table has a few columns. The first column is hidden. It is initialised using:

[code]
this.Table.dataTable({
"bAutoWidth": false,
"aoColumns": [
{ "bSearchable": false, "bVisible": false, "mDataProp": "foo" },
{ "mDataProp": "bar" },
{ "mDataProp": "foobar" }
],
"oLanguage": {
"sEmptyTable": "No records.",
"sInfo": "Showing records _START_-_END_ of _TOTAL_.",
"sInfoEmpty": "",
"sInfoFiltered": "",
"sZeroRecords": "No records to display: nothing matches the filter.",
"sPaginationType": "full_numbers",
"sLengthMenu": "Show _MENU_ records per table.",
"sSearch": "Search:"
}
});
[/code]

and at any time populated using:

[code]
this.Table.fnClearTable();

this.Table.fnAddData(data);

this.Table.fnSort([[1, "asc"]]);
[/code]

There's a difference in sort order when the code that populates and sorts the table is run initially and later. Initially, it seems that the table is sorted on the second column (first visible), and then on the first column, which is not visible, like so:

[code]
a | A | a
a | B | z
b | B | b
c | B | a
a | C | a
[/code]

When the table is later sorted, the sort order is second column (first visible), and then third column. This is what I wanted it in the first place and how the array passed into "fnAddData" is actually sorted.

[code]
a | A | a
c | B | a
b | B | b
a | B | z
a | C | a
[/code]

allan

This is an interesting one. Because you are initialising the table with the default aaSorting ([[0, 'asc']]) that is what the initial sort is. The bSortable flag is actually only being used to not apply the sorting listener to the column header, rather than rejecting the sort on that column when called internally (or by fnSort)! I think this is a bug and should be fixed. However, for the moment what you could do is change the initial sorting to be an empty array (i.e. no sorting) or to have it on the second column.

Allan

drumex

Thanks for that Allan, I've fixed it by including the "aaSorting" option during intialisation.

To help you fix the bug, I should point out that when the table is initialised, there are actually no rows in the tbody element. So, the table was indeed being initialised with the default values for sorting, but the first time it ever displayed any rows was by using the fnClearTable-fnAddData-fnSort chain I posted above. So what puzzles me is why it should even matter what the default sorting order is in a situation like this.

allan

The reason this occurs is because the internal sorting will be fired off again when you add new data. I suspect that if you changed the order to fnClearTable-fnSort-fnAddData that would address the problem. This is also another reason why the internal sorting methods should check that columns are sortable before actually sorting them...

Allan