Replies

• allan Posts: 63,498Questions: 1Answers: 10,470 Site admin

  December 2012

  Its the column index - so bSearchable, bVisible etc are not taken into account.
  
  ColReorder will cause the indexes to change (since the column indexes change). You generally need to map from the column index to the `mDataProp_{i}` that is sent to the server.
  
  Allan
• CGRemakes Posts: 32Questions: 1Answers: 0

  December 2012 edited December 2012

  Let me see if I can explain kinda what I'm talking about. I'm currently using the sName approach, rather than mDataProp. If it'll make a difference, I'll try that, but I don't think it will based on the issue I'm having. One major thing to note that seems to factor into this is "submit_date" and "process_date" are both hidden by setting the bVisible value to false for aoClumnDefs at initialization. I'll see if I can get a functioning demo setup in a bit, but for now, I'll just post the variables being passed to my script from DataTables.
  
  These are some of the values from when the table is first generated, the table is sorted on the second column called "invoice_num" (index #1) in sColumns (because there are 47 columns, I'm just going to display part of the output):
  
  [code]
  bSearchable_1 true
  bSortable_1 true
  iSortCol_0 1
  iSortingCols 1
  mDataProp_1 1
  sColumns col_data,invoice_num,submit_date,process_date,ship_date,company_id,customer_id,customer_name,zip,line_num,quote_num,location,ord_cde,carrier_partner_id,product_select_code,catalog_number,serial_num,price,actual_cost,recalc_cogs,rebate_ext,rfi,psi,status,original_submit_date,manual_change_date,creation_date,general_status,general_status_description,detail_status,detail_status_description,type_of_sale,brand_original_sales,quote_line_num,quote_type,approved_dist_sell,buy_price,validated_pc,claim_adjustment,claim_num,distributor_gm_per,job_name,notes,best_quote_num,credit_memo_num,credit_memo_date,dealer_sap_num
  sSearch_1
  sSortDir_0
  [/code]
  
  I then drag that "invoice_num" column to the 6th position (index #5). If you notice, the sColumns shifts the "invoice_num" to the correct position, and the iSortCol_0 value is adjusted accordingly.
  
  [code]
  bSearchable_5 true
  bSortable_5 true
  iSortCol_0 5
  iSortingCols 1
  mDataProp_5 5
  sColumns col_data,submit_date,process_date,ship_date,company_id,invoice_num,customer_id,customer_name,zip,line_num,quote_num,location,ord_cde,carrier_partner_id,product_select_code,catalog_number,serial_num,price,actual_cost,recalc_cogs,rebate_ext,rfi,psi,status,original_submit_date,manual_change_date,creation_date,general_status,general_status_description,detail_status,detail_status_description,type_of_sale,brand_original_sales,quote_line_num,quote_type,approved_dist_sell,buy_price,validated_pc,claim_adjustment,claim_num,distributor_gm_per,job_name,notes,best_quote_num,credit_memo_num,credit_memo_date,dealer_sap_num
  sSearch_5
  sSortDir_0
  [/code]
  
  In the "invoice_num" column, I type in a search for just that column for "3813", and this is the output:
  
  [code]
  bSearchable_5 true
  bSortable_5 true
  iSortCol_0 5
  iSortingCols 1
  mDataProp_5 5
  sColumns col_data,submit_date,process_date,ship_date,company_id,invoice_num,customer_id,customer_name,zip,line_num,quote_num,location,ord_cde,carrier_partner_id,product_select_code,catalog_number,serial_num,price,actual_cost,recalc_cogs,rebate_ext,rfi,psi,status,original_submit_date,manual_change_date,creation_date,general_status,general_status_description,detail_status,detail_status_description,type_of_sale,brand_original_sales,quote_line_num,quote_type,approved_dist_sell,buy_price,validated_pc,claim_adjustment,claim_num,distributor_gm_per,job_name,notes,best_quote_num,credit_memo_num,credit_memo_date,dealer_sap_num
  sSearch_3 3813
  sSearch_5
  sSortDir_0
  [/code]
  
  If you'll notice, the iSortCol_0 value is 5, which is correct. However, the sSearch_5 (the column on which I'm searching) is blank. The value I'm typing appears in the sSearch_3, which would be the column if we ignore the columns that are not visible. If I do the same steps, but don't hide those 2 columns beforehand, it works as expected. I'm using the following:
  
  Chrome 23.0.1271.97 m
  DataTables 1.9.4
  jquery 1.8.3
  jquery ui 1.9.2
  FixedColumns 2.5.0.dev
  Scroller 1.1.1.dev
  ColReorder 1.0.8
  
  Wonder if it could be related to the issue reported here: http://datatables.net/forums/discussion/5363/colreorder-sorting-issue-shown-in-your-demo/p1
• allan Posts: 63,498Questions: 1Answers: 10,470 Site admin

  December 2012 edited December 2012

  Thanks for the detailed description. How are you using fnFilter with the index being passed in? I'm guessing there is a closure in your event handler there and it isn't taking into account the updated column indexing - possibly?
  
  v.1.10 will allow sName to be passed into fnFilter (or rather you'll use `column( selector ).filter( value )` method I think) which will be much more flexible.
  
  Another option is that there is a closure in DataTables somewhere, but since fnFilter for column filtering is called externally, I would guess its the external code.
  
  Allan
• CGRemakes Posts: 32Questions: 1Answers: 0

  December 2012 edited December 2012

  Ah, I bet you're right. The code would just look at what is in the table, so it wouldn't know about the hidden columns. This is what I have:
  
  [code]
  $('tfoot input:visible').keyup(function(){
  
  oTable.fnFilter(this.value, $("tfoot input").index(this));
  });
  [/code]
  
  Any suggestions on how to compensate for when the column is hidden?
  
  EDIT: Well, I have a working solution, though I sense it is probably not the most efficient or eloquent. I get the correct index from sColumns and pass that instead. This is my code:
  
  [code]
  var col_search = $(this).attr('id').replace(/_search$/, '');
  var oParams = oTable.oApi._fnAjaxParameters(oTable.fnSettings());
  var s = String($.param(oParams).match(/&sColumns=(.+?)&/)).substring(10);
  var a = s.split("%2C");
  a[46] = a[46].replace(/&,col_data/, '');
  var sel_index = $.inArray(col_search, a);
  
  oTable.fnFilter(this.value, sel_index);
  [/code]
  
  Any pointers are certainly welcome. Thanks again for the help, I've been wracking my brain for quite some time over this!
• allan Posts: 63,498Questions: 1Answers: 10,470 Site admin

  December 2012

  > Any suggestions on how to compensate for when the column is hidden?
  
  Yes - use this plug-in: http://datatables.net/plug-ins/api#fnVisibleToColumnIndex :-)
  
  Allan
• CGRemakes Posts: 32Questions: 1Answers: 0

  December 2012 edited December 2012

  I've seen that plugin before, but there's not much information on how it works. What value corresponds to iMatch?
  
  EDIT: Nevermind, found the answer here: http://datatables.net/forums/discussion/10147/column-filtering-on-columns-to-the-right-of-hidden-columns-not-working/p1
  
  [code]
  $('tfoot input:visible').keyup(function(){
  
  var col_index = oTable.fnVisibleToColumnIndex($("tfoot input").index(this));
  
  oTable.fnFilter(this.value, col_index);
  });
  [/code]
• allan Posts: 63,498Questions: 1Answers: 10,470 Site admin

  December 2012

  I think you can probably shorten the parameter passed into the plug-in to `$(this).index()`, but yes, that's the idea.
  
  Allan
• CGRemakes Posts: 32Questions: 1Answers: 0

  December 2012 edited December 2012

  Get an error if I shorten it to that: "JSON data from server could not be parsed". Even in your demo on this page: http://www.datatables.net/examples/api/multi_filter.html, it uses $("tfoot input").index(this). Not a biggie, I'll just leave it as is.
• allan Posts: 63,498Questions: 1Answers: 10,470 Site admin

  December 2012

  Yeah - demo page is from before I realised `index()` does the short form version :-). I'll update it at some point. However, as long as you've got a working solution, all is good.
  
  Allan