Resizing the last column in a table causes unnecessarly width change eventsResizing 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

N/A

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.

 xxxxx@xxxxx  2003-09-11

Fix verified on Win2003SE for build 1.4.2_05-ea-b01
 xxxxx@xxxxx  2004-04-29