Table.setWidth(-1) does not autoscale column width

Hi,

when a user is sizing the columns of a table and want to revert these manual settings, I have created the possibility to set all columns width to -1. According to the API (Setting width to -1 (default) means that theme will make decision of width), this should auto scale the columns. Unfortunately, I have to close the Table and create it again to get the auto scaling working. If I don’t close/create the Table, the column widths stay the same with the fixed sizes.
Even resizing the parent container doesn’t bring the auto scaling back.

What do I have to do, to get the auto scaling working again
without
closing and re-creating the Table?

Best regards

Andreas

I have a feeling that that can be quite hard to achieve. The client side is built up in a way that once the user touches any sizes, all sizes will become defined and nothing will automatically resize anymore. I still have a (untested) hunch on how you could achieve this. Table has a experimental feature in it, in form of a field:

    /*
     * EXPERIMENTAL feature: will tell the client to re-calculate column widths
     * if set to true. Currently no setter: extend to enable.
     */
    protected boolean alwaysRecalculateColumnWidths = false;

What I looked at the client side code, if that returns true, the client skips setting all the cells (and through that columns) to defined with. Try setting that field to true and see what happens. As the comment says, you have to extend table to be able to toggle it.

BTW, what do you mean with “closing table”?

Hi Jens,

thank you for your very fast answer!

I did what you suggested: I created a little method in my Table like:

  public void resetColumnWidths()
  {
    alwaysRecalculateColumnWidths = true;
    for (Object object : getVisibleColumns())
    {
      setColumnWidth(object, -1);
    }
  }

When I call this method to switch automatic scaling on, the header and footer columns have a different width (in my case smaller) than the cells between header and footer. Looks funny. But when I resize the parent container,
all columns
will be auto scaled as they should be!

Now I need to know, how to force this resizing event in code? I tried setWidth(“90%”) and setWidth(“100%”) directly after another, but that didn’t help.

[quote=Jens Jansson]
BTW, what do you mean with “closing table”?
[/quote]Well, I meant destroy.

Hi Jens,

could you please tell me, how to force a Table (in source code) to adjust the column widths?

Regards

Andreas

sounds like a bug to me in that feature then. As it was stated, it is just an experimental feature. What you can still try is calling table.requestRepaint() after that you’ve switched the boolean to true. If that doesn’t work, I don’t really know what will :frowning:

Hi Jens,

I tried some variations of the order of statements in my routine but nothing helped. Then I tried another approach that you see here:

  public void resetColumnWidths()
  {
    alwaysRecalculateColumnWidths = true;
    for (Object object : getVisibleColumns())
    {
      setColumnWidth(object, -1);
    }
    if (getVisibleColumns().length > 0)
    {
      Object col = getVisibleColumns()[0]
;
      boolean b = isColumnCollapsed(col);
      setColumnCollapsed(col, !b);
      setColumnCollapsed(col, b);
    }
  }

The second if statement is either collapsing/uncollapsing or uncollapsing/collapsing the first column. And this workaround is forcing the table to scale all columns!

Should I file a ticket or will you do this?

Andreas

Looking from the VScrollTable code, column width recalculation is triggered by a couple of things e.g. setting table width or setting a width of a column. It seems that although there’s a flag for always recalculating widths of columns i.e. setting their size undefined, that actually doesn’t trigger the recalculation, but instead you need something else to trigger it as you have found out. And for the workarounds I would add that having that alwaysRecalculateColumnWidths as true and having a fixed width at least in one column also triggers the recalculation of columns. But yeah I would file a ticket for it if there’s not one already.

I created a ticket:
#7922