Jay, Am I right in understanding that you're expecting the table, when unconstrained, to grow until each column can occupy its preferred width? It should be possible to achieve that, although just setting preferred size may not be enough. There used to be a setColumnWidth() method that would set a column's size, but still allow it to be resized later. I don't know what the gen2 PST equivalent would be, but I can dig around a bit later if I get some time.
On Mon, May 11, 2009 at 1:14 PM, jay <[email protected]> wrote: > > But if I set the min and max sizes, then the user cannot resize the > columns. And...well, my users need to be able to resize the columns... > > So, I guess I should enter a feature request (or else provide a > patch ;-) that there some way for the table to set the initial column > width to the preferred width. > > jay > > On May 7, 6:08 pm, John LaBanca <[email protected]> wrote: >> If you want the columns to be an exact size, set the minimum and maximum >> column widths and call resetColumnWidths() or set the resize policy to >> FIXED. >> The preferred width is exactly that, the width that the columns should >> attempt to maintain if they can. When the resize policy is set to >> FILL_WIDTH, the table will update the column widths on every page load. >> When it is set to anything else, you must update the width manually >> (although that is probably a bug). Either way, the preferred width is not >> guaranteed, but the minimum and maximum widths are. >> >> Thanks, >> John LaBanca >> [email protected] >> >> >> >> On Thu, May 7, 2009 at 7:11 PM, jay <[email protected]> wrote: >> >> > I've set my table resize policy to UNCONSTRAINED. I then very >> > carefully setup my ColumnDefinitions to have the right preferred size >> > (because the user may have previously resized the columns, and I need >> > to honor that size). >> >> > What I've noticed, though, is that "out-of-the-box", my columns are >> > *always* 80px wide (which seems to correspond to >> > FixedWidthGrid.DEFAULT_COLUMN_WIDTH. >> >> > It seems to me (and please...correct me if I'm misusing/abusing the >> > PagingScrollTable) that when I set the table definition, it should be >> > setting the column widths to their preferred size, rather than >> > allowing the default size to kick in. >> >> > FWIW, my work-around is to override setTableDefinition() as follows: >> >> > �...@override >> > public void setTableDefinition( >> > TableDefinition<RowType> tableDefinition >> > ) { >> > super.setTableDefinition( tableDefinition ); >> > refreshVisibleColumnDefinitions(); >> >> > List<ColumnDefinition<RowType, ?>> columns = >> > getVisibleColumnDefinitions(); >> > for ( int index = 0, numCols = columns.size(); index < numCols; >> > index++ ) { >> > setColumnWidth( index, columns.get >> > ( index ).getPreferredColumnWidth() ); >> > } >> > } >> >> > Would problems be caused if this behavior was in the base class? (My >> > goal is to have the PagingScrollTable "just work". I'll be the first >> > to admit that what I consider "just working" may not work for >> > others...) >> >> > thanks, >> >> > jay > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
