sWidth not working after 1.7 upgrade

sWidth not working after 1.7 upgrade

kpm47kpm47 Posts: 6Questions: 0Answers: 0
edited August 2010 in Bug reports
After upgrading to v1.7, the sWidth property on columns seems to no longer work. I'm adding a column like this:
[code]newCol = [{"sTitle": "", "sClass": "center", "sWidth": "17px", "bSortable": false, "bSearchable": false, "fnRender": function(oObj){...}}];[/code]
However, the widths of the columns (via the TH cells) are being automatically calculated to fit the width of the table's container. No other properties are set for this column. General table properties include:
[code]sPaginationType = 'full_numbers';
bJQueryUI = true;
[/code]
This worked just fine in the previous version with no change to the properties or the JavaScript that generated them.

Replies

  • allanallan Posts: 63,494Questions: 1Answers: 10,470 Site admin
    Can you provide us with a link for this please?

    Thanks,
    Allan
  • kpm47kpm47 Posts: 6Questions: 0Answers: 0
    Sure - here's a quick example: http://www.kirkmorales.com/datatables/

    Thanks,
    Kirk
  • kpm47kpm47 Posts: 6Questions: 0Answers: 0
    I also made a page with v1.6.2 to show how they're rendering different: http://www.kirkmorales.com/datatables/old.htm
  • allanallan Posts: 63,494Questions: 1Answers: 10,470 Site admin
    Hi kpm47,

    Thanks very much for the links - very useful! There are actually two issues here. The first is with the sWidth 17px not being correctly applied - this is due to a bug in the _fnGetMaxLenString function: the first line "var iMax = 0;" should be "var iMax = -1;". This will be fixed in the next release.

    The second issue is the one you point out about the width of the table expanding to the container's width. This is due to the line:

    [code]
    nCalcTmp.style.width = _fnStringToCss( nWrapper.offsetWidth );
    [/code]
    which was indeed added for 1.7. I'm not sure if this is right or wrong. The behaviour is the same as a block level element in CSS 2.1 - it takes 100% width unless told otherwise, but then it isn't the same behaviour as the table element on it's own by the looks of it where it collapses down to size. I'm honestly not sure what the right thing to do here is... if it doesn't have any impact on scrolling, then I'm tempted to remove it.

    Regards,
    Allan
  • allanallan Posts: 63,494Questions: 1Answers: 10,470 Site admin
    A quick update - I do indeed plan to alter this behaviour in DataTables 1.7.1. When scrolling is enabled, behaviour like this will be applied - when there is no scrolling, then the width will not be fixed like that.

    Regards,
    Allan
  • DiogoDiogo Posts: 1Questions: 0Answers: 0
    Hi Allan,

    it seems that sWidth still not working in DataTables 1.7.1

    http://www.agoravale.com.br/diogo/datatables.html

    Thank you
  • allanallan Posts: 63,494Questions: 1Answers: 10,470 Site admin
    Hi Diogo,

    Thanks very much for the link - that was really useful!

    The problem is basically the column width calculation is currently being done in what I would (now ;-) ) consider to be the wrong place. It's being done before the TH elements for the header are being put in place - so 1. it's not including the column titles in the width calculation, nor 2. is it actually putting the widths onto the headers - since they don't exist!

    So I think this is a different issue from the original one, but no less valid.

    The current fix I'm thinking off is to remove the call to "_fnCalculateColumnWidths" (line 6539) and make that call just after the call to _fnDrawHead (line 2192). So:

    [code]
    _fnDrawHead( oSettings );
    _fnCalculateColumnWidths( oSettings );
    [/code]
    Before committing that, I want to experiment a little more and see if there are any side effects... :-)

    Regards,
    Allan
  • MikeSMikeS Posts: 113Questions: 1Answers: 0
    Hey Allan,
    Were you able to find out anymore about this?
  • allanallan Posts: 63,494Questions: 1Answers: 10,470 Site admin
    I've not had a chance to experiment with it yet, but I've been thinking about it, and think my suggestion above is correct. The call to _fnCalculateColumnWidths should be done after DataTables has done it's DOM manipulation - which is after the header has been drawn... I can't think of any draw backs at the moment...

    Allan
This discussion has been closed.