Community
Participate
Working Groups
I have a table in my properties page, with two columns, using ColumnWeightData for the columns. If this page is the first page to come up when the dialog opens, then the columns are scrunched together. It appears that the client area is computed incorrectly for the table. If, however, another page is the default when the dialog opens, and you switch to this page, then the columns are distributed evenly. My workaround for now is to use ColumnPixelData, but that is not optimal because in that case the columns don't size proportionally when switching from another page.
ColumnWeightData is part of JFace. Moving to UI for consideration.
TableLayout only runs once, so the problem must be that the initial clientArea is too small when the initial layout is computed.
Please investigate.
Checking through all of the places where we use the ColumnWeightData we don't exhibit this problem. Could you please send us some details as to what widgets are in the page and how they are laid out? I suspect that your properties page has a different layout look.
You can recreate this with the Team->File Content prefs page, accessible from Window->Preferences. Navigate to the page once; notice that the columns distribute proportionally accross the table. Now close the prefs window with this page focused, and reopen. Notice the columns are now not distributed accross the table.
I have replicated the fact that the coluymnswill only size thier required size when they are created and a full 50% when they are not. Are you losing any information - i.e. when you say scrunched doi you mean minimum size or too small? Reducing priority to P3.
In my case they are sizing too small, so that information is truncated within the columns and you have to manually resize the columns to make the truncated text visible. I suspect if we searched we could find other preference or property pages where the same thing happens.
The problem is that the TableLayout gets told to layout twice, once when the page's controls are packed using pack(), and again when the overall size of the dialog is determined. It's not clear that we can avoid this. For a workaround, see bug 13467. Recommend adapting the TableResizing example by Veronika in your page. This will let the table adjust its column widths on every resize, not just the first.
Took out the extra pack() call from PreferenceDialog$PageLayout.layout(). This was doing extra layouts which were overridden by the subsequent setSize(). Verified that all preference pages in the SDK work fine with this change. The workaround suggested above will not be needed with this change. This will be available in Tuesday's integration build (July 16) and in the nightly builds.
Needs to be released in 2.0.1 stream.
Released into 2.0.1 stream
