Problems with table growth out of div with filter edits, or sorting, and double tall headers

Problems with table growth out of div with filter edits, or sorting, and double tall headers

ghowlandghowland Posts: 6Questions: 0Answers: 0
edited September 2010 in Bug reports
Hey, great library!

I have a formatting issue, which could be how I'm using it, but Im unclear on how to fix it.

Here is the link to a demo:

http://ge01f.com/test/system_monitor/monitor

Im using FF 3.6.10 on OSX at the moment, but also a current version on Linux as well, and it appears to be the same issue on both browsers. I have not tested with other browsers.

The 3 styling problems I cant seem to change positively are (in order of importance):

1) When typing in filter, for each key stroke, the table grows wider. Growing out of the tab that it resides in. I've tried doing things I read in the forums, setting zoom:1, on a containing div after, trying to just set width:100% everywhere. These didnt help though. Similarly, the sort function also does this.

Can you see what I'm doing wrong here?

2) On the second tab, "Graphs", when the graph list is created (by clicking on a checkbox on a host on the first tab), the table comes up with the headers crunched to the side, even though the rows are spread out normally across the width of the table.

3) On all the tables, the headers are double tall. The pointer arrow is on a separate block line than the text, and they are also spread far apart from each other.

Other than these remaining issues, your tables have been tremendously useful, and Im looking forward to figuring this out making more use of them. :)

Thanks in advance!

-geoff

Replies

  • ghowlandghowland Posts: 6Questions: 0Answers: 0
    Oh yeah, only the "monkey.ge01f.com" machine has graphs to list, so you need to check that one, or Select All, to see the issue #2.

    -g
  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin
    Hi geoff,

    1. That is the oddest thing! I suspect that the width issue is caused by a sizing error at initialisation which just gets worse whenever the table is redrawn (i.e. typing in the filter). Clicking to sort does it as well.

    Could you possibly try the initialisation with "bScrollCollapse": true please? Also, it would be worth making your HTML valid, as it is possible that there is something is causing the initial width issue. I'd also suggest removing the "bDestory" in the initialisation since you don't need that (although I don't believe it will make any difference).

    2. When the tab is made visible you need to call "fnAdjustColumnSizing" - http://datatables.net/examples/api/tabs_and_scrolling.html

    3. This is CSS issue - since you are using DataTables 1.7.2 with jQuery UI theming, it would be worth using something like the CSS that DataTables uses:

    [code]
    table.display thead th div.DataTables_sort_wrapper {
    position: relative;
    padding-right: 20px;
    padding-right: 20px;
    }

    table.display thead th div.DataTables_sort_wrapper span {
    position: absolute;
    top: 50%;
    margin-top: -8px;
    right: 0;
    }
    [/code]
    Allan
  • ghowlandghowland Posts: 6Questions: 0Answers: 0
    Hey Allan,

    1) I tried bScrollCollapse and turning off bDestroy, and no change in effect. I think bDestroy is needed, since I re-create these data tables all the time with the same names, but turning it off didnt do anything.

    The bScrollCollapse did make the table slightly shorter, initially, with the scroll bar, but still grew when filtered.

    2) Ill set up an event for the tab change and call fnAdjustColumnSizing, this should be straight forward. The entire page, except for a template outline, is being generated from code, so I have to go back and find a good way to do this, as not all the pieces necessarily know about other pieces, or what they are.

    3) Just adding in that CSS didnt do it, but Ill play with it. I realize it's probably because of theme roller. :) This one is not a big deal at the moment, Im really only concerned with #1, as it quickly becomes unusable when it scrolls off the screen. :)

    Ill run it through an HTML validator and see if there are any unclosed tags, I dont think there should be though.

    -geoff
  • ghowlandghowland Posts: 6Questions: 0Answers: 0
    I went through and fixed all the HTML validation issues W3C complained about, mostly using old tags and attributes instead of CSS. No change to the page though.

    Im at work at the moment, so cant update the test page I put up to show you accordingly. I can do that tonight if it helps.

    I'm good on #2 and #3, but #1 is a show stopper. Any ideas? If not, I'll post the new version to the test link when I get home tonight.

    -geoff
  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin
    Hi Geoff,

    Thanks for the feedback. Regarding point 1, you might be interested in this thread: http://datatables.net/forums/comments.php?DiscussionID=2680 . It seems that it is effecting a few others, but I haven't been able to reproduce it in my own examples, so it's fairly hard to debug. It would appear that setting a fixed width for the table will fix it:

    [code]
    .dataTables_wrapper {
    width: 700px;
    }
    [/code]
    I'll continue my investigation and post back...

    Allan
  • ghowlandghowland Posts: 6Questions: 0Answers: 0
    Just noticed an interesting difference, present in my test URL. On the second tab, where the fnAdjustColumn needs to be called, the table is always the right size.

    The original tab the table overruns from page load, but the second tab, the table is the right size. If you type into the filter on either of these, the tables expand. I tested this with tables without widths set (short), and they still expand and overrun.

    The second tab table DOESNT expand on the sort though, and the first tab tables do expand on sort. So there seems to be a difference between that in the code.

    All 3 tables (2 on first tab, 1 on second tab) are generated with the same code, and are wrapped in from the same code generator, so all things about them should be the same, except their IDs of course, which are also programmatically different.

    Not sure if this gives you any ideas, but since I noticed it was working properly with the Sort on the 2nd tab, I thought it might give you something to go on.

    -geoff
  • ghowlandghowland Posts: 6Questions: 0Answers: 0
    Hey Allan,

    Thanks! The fixed pixel sizing seems to work. Not ideal, but at least things are usable this way and I can do a launch tomorrow. :)

    Let me know if you find a % fix, as that would be ideal. I think I may end up getting the container size and just doing it with JS so it's dynamically fixed, if we cant get around it.

    -g
  • arenaazarenaaz Posts: 1Questions: 0Answers: 0
    i think i've found a way to reproduce the problem.

    the prerequisites seem to be:
    1. a around the datatable
    2. very few rows in the datatable

    i was able to reproduce the problem with the datatable in scroll_y_theme.html.

    to elaborate, it doesn't seem to matter how "far" the surrounding is from the datatable, so long as there aren't any block elements with fixed-pixel width in between. as to the number of rows in the datatable, it has to be so few that the vertical scrollbar is hidden, regardless of sPaginationType.
This discussion has been closed.