Replies

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

  January 2013

  I suspect the issue is that the row height initially calculated does not take into account the height of the checkbox. You could either use CSS to make the row height larger for all rows, or the Scroller API should be able to recalculate the size - which you would do in fnInitComplete once the table has been drawn: http://datatables.net/docs/Scroller/1.1.0/Scroller.html#fnMeasure
  
  Allan
• CGRemakes Posts: 32Questions: 1Answers: 0

  January 2013 edited January 2013

  I bumped the height value of all the elements to 25, but all that seems to do is make the cells larger (Firebug confirms that the height is simply 5 greater than it was before). The values are still not correct. This is what I have for the css:
  
  [code]
  
  #tabs-1 td { height:25px; min-width:75px; white-space:nowrap; border-right:1px solid #888; border-top:1px solid #888; padding:2px; }
  
  [/code]
  
  I also tried setting the fnMeasure in the fnInitComplete. This is my code:
  
  [code]
  
  "fnInitComplete": function(){
  
  var oSettings = this.fnSettings();
  
  $('tfoot input:visible').each(function(){
  
  var index = $("tfoot input").index(this);
  $(this).val(oSettings.aoPreSearchCols[index].sSearch);
  
  if(this.value == "")
  {
  $(this).addClass('search_init');
  
  this.value = asInitVals[$("tfoot input").index(this)];
  }
  });
  
  oFC = new FixedColumns(oTable, {"sRightWidth": "fixed", "iLeftWidth": 25});
  
  oSettings.oScroller.fnMeasure();
  }
  [/code]
• allan Posts: 63,498Questions: 1Answers: 10,471 Site admin

  January 2013

  Hum - I just realised - FixedColumns is not compatible with Scroller - in fact I'm surprised it isn't throwing errors. If you disable FixedColumns does it work as expected?
  
  Allan
• CGRemakes Posts: 32Questions: 1Answers: 0

  January 2013 edited January 2013

  Nope, doesn't make any difference. Seems to be more related to having borders on the table cells. It's almost like it's calculating based on the height, not the outer height. If I remove the specified height and the border, it calculates much more correctly. I've had great luck with FixedColumns/Scroller combined, no issues whatsoever. I've updated the demo to reflect my findings. Strange thing is I swear this was working flawlessly with borders up until a day or 2 ago. Don't know what I had different then.
• allan Posts: 63,498Questions: 1Answers: 10,471 Site admin

  January 2013

  I think it should work with borders - but it certainly won't with cellspacing. But it doesn't look like you have any. I think I'll need to take a closer look at your demo and debug Scroller properly. Unfortunately I can't do that until the end of the month at the moment due to time constraints on other projects.
  
  Allan
• CGRemakes Posts: 32Questions: 1Answers: 0

  January 2013 edited January 2013

  Well, some more interesting findings. I commented out the document.body.removeChild( nContainer ); portion of the _fnCalcRowHeight function in the scroller script, just so I could see what it was basing the height off of, and it displays the cloned row, but it has no borders, which would explain why it's not factoring that into the height when they are present. I don't think that will be a problem in my case, because I think I like the look of only having a right border and just relying on the alternating colors to separate rows from each other, but maybe something to factor in the future.
• allan Posts: 63,498Questions: 1Answers: 10,471 Site admin

  January 2013

  If you remove the input elements, does it then work?
  
  Allan
• CGRemakes Posts: 32Questions: 1Answers: 0

  January 2013 edited January 2013

  Nope, it still is doing the same. It seems to be more related to not copying the border information to the clone used to determine the height than the input. I went ahead and made a copy of the scroller script and just commented out that 1 line just to reflect what seems to be the case. It isn't apparent that it's off until you scroll down to the bottom. On a "somewhat" related note, I figured out it also doesn't like if you have the datatable in a tab. The row just returns as a blank ( ), so in my case, it was not factoring in the extra height for the input. The way I got around this was to just stick a dummy row in my html (not json):
  
  [code]
  
   
  
  [/code]
  
  I didn't include the tabs in the demo, more just an FYI.
  
  
  EDIT: Boy, did I ever over-think the solution. I didn't notice the rowHeight option of scroller. I just needed to specify that to the same value as my height value in css and it worked much better.