Bug ID: JDK-4895084 JTable: Weird column resizing behavior in auto resize modes

Type: Bug
Component: client-libs
Sub-Component: javax.swing
Affected Version: 1.4.2

Priority: P2
Status: Closed
Resolution: Fixed
OS: solaris_8
CPU: generic

Submitted: 2003-07-23
Updated: 2004-04-29
Resolved: 2003-09-26

Other	Other
1.4.1_07 07Fixed	1.4.2_05Fixed

Resizing the last column in a table using the right most handle causes
property change events to be sent on the width of the column even if
the column width does not change visualy.

You can see that events are sent using addPropertyChangeListener()
on the last column and listening to "width" changes.

To reproduce:

- Try resizing the last column using the right most handle.
- If you attempt to resize the frame after that, the column instantly
  colapses to a different size.

Impact:

We cannot reliably determine the width of the column.

Testcase: Testcase is attached to this bug report

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_07 1.4.2_05 generic tiger FIXED IN: 1.4.1_07 1.4.2_05 tiger INTEGRATED IN: 1.4.1_07 1.4.2_05 tiger tiger-b22 VERIFIED IN: 1.4.1_07 1.4.2_05
14-06-2004
SUGGESTED FIX ------- JTable.java ------- * //C/tmp/sccs.001000 Fri Sep 12 11:34:38 2003 --- JTable.java Fri Sep 12 11:28:34 2003 *********** * 1,5 **** /* ! * %W% %E% * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. --- 1,5 ---- /* ! * @(#)JTable.java 1.220 03/09/12 * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. ************* * 127,133 **** * attribute: isContainer false * description: A component which displays data in a two dimensional grid. * ! * @version %I% %G% * @author Philip Milne * @author Shannon Hickey (printing support) / --- 127,133 ---- attribute: isContainer false * description: A component which displays data in a two dimensional grid. * ! * @version 1.220 09/12/03 * @author Philip Milne * @author Shannon Hickey (printing support) / ************ * 2269,2274 ** --- 2269,2275 ---- if (delta != 0) { resizingColumn.setWidth(resizingColumn.getWidth() + delta); } + setWidthsFromPreferredWidths(true); } super.doLayout(); *********** * 2312,2317 ** --- 2313,2319 ---- else { int delta = getWidth() - getColumnModel().getTotalColumnWidth(); accommodateDelta(resizingColumn, delta); + setWidthsFromPreferredWidths(true); } } } *********** * 2392,2399 **** adjustSizes(totalWidth + delta, r, false); - setWidthsFromPreferredWidths(true); - // setWidthsFromPreferredWidths(false); return; } --- 2394,2399 ----
11-06-2004
PUBLIC COMMENTS Resizing the last column in a table causes unnecessarly width change events
10-06-2004
EVALUATION There are really two issues here. The first issue is the delivery of width change events when the column doesn't change visually. The column isn't changing visually because its size is being restored back based on logic in JTable. Any PropertyChangeListeners registered on the column will see multiple width change events (one for the original resize and one when it is being resized back). They will therefore ALWAYS be in synch with the size of the column. Therefore, the claim that one cannot reliably determine the column width is invalid. The next section provides more details on WHY this behavior is: When the mouse is dragged, the width of the column is changed. A "width" notification is sent to all listeners including the table itself. The table attempts to redistribute the space based on the resize mode. If it is impossible to do so (there are MANY cases where this can occur, not just the last column) then it prevents the resize by restoring the size of the column. In effect, the column size never changes and therefore a change is never shown on the screen. Two events will be sent...one changing the size, one changing it back. The developer's code will receive both events and can stay consistent with the actual column size. This may not be optimal, but it is valid and necessitated by the current architecture. --- The second issue, is what I beleive to be the real problem and, in fact, I believe it is being confused with the previous issue. This occurs when resizing the window after a previous failed attempt to resize a column. The column suddenly jumps to a larger or smaller size. This makes it APPEAR as though the column was previously resized, but without a visual update. This isn't really the case though, and any PropertyChangeListeners will continue to be in synch. However, this behavior is a bug and doesn't look nice. It will be fixed. The problem here is that when a width change is restored in doLayout(), we have already updated the preferred size of the column based on what we thought the size would be. With a subsequent window resize, we are therefore giving this column more (or less) space based on this incorrect preferred size. Updating of the preferred sizes should come only after we have settled on sizes for all columns. --- By the way, I mentioned previously that these issues result from JTable being unable to distribute a change in space under certain conditions. These scenarios follow logically from the specifications for JTable's auto resize modes. But I'll give one example here: If the JTable is in AUTO_RESIZE_NEXT, this means that the space change from resizing a column should be accommodated by the column after it. If the column being resized is the last column, there are no columns after it. Therefore, there is nowhere to distribute the space, and the change in width to that column is prevented. ###@###.### 2003-09-11 Fix verified on Win2003SE for build 1.4.2_05-ea-b01 ###@###.### 2004-04-29
11-09-2003