>> Cargo-cult code.
>
[quoted text clipped - 6 lines]
> nor the reason the code apparently avoided the bug was ever fully
> understood.
> Dr. Heinz Kabutz:
>
[quoted text clipped - 6 lines]
> to check whether the row was already the correct height before setting
> it."
> Yes, in fact my interface has two tables in side-by-side scoll panes.
> This allows me to synchronize row selections between two tables with
> rows of varying heights. The application generates the table data,
> which varies in length.
> Do you understand why this stuff with overriding setBackground/set-
> Foreground and invoking super.setBackground/Foreground was done? Is it
> useful that way?
I don't know why Wernitz overrode setBackground/Foreground; I did not
focus on that. I commented it out, and the table stills acts as I
expect in my test. As I understand, super.setBackground/Foreground is
used to reproduce highlighting/borders for selected rows/cells.
Without it, there is no indication of selection. Is there a different,
standard way this should be done?
> * It fails unless all renderers agree on a row height. Otherwise the row
> height will switch randomly, or even pseudo-recursive as each layout/
> painting will cause relayout/repainting.
I see your point. Although the JTextArea's getPreferredSize()
calculates the size of the component based on its contents (and so
implies the cell's height), it is unnecessary to calculate the height
each time the cell is rendered. I should use the renderer's
getPreferredSize() method at a more appropriate time.
The row height shall be equal to the maximum of its cells' heights.
Wernitz iterated through all columns in a row to determine the maximum
height. In a dynamic table, it seems necessary to (re)calculate the
row height whenever a cell is initialized or edited. In my case, my
tables are static, so I only need to worry about calculating the row
height when a row is added. I guess I will use a TableModelListener to
listen for an INSERT. If I had a dynamic table, would I simply need to
also listen for an UPDATE? That is, is the TableModelEvent guaranteed
to be fired when the contents of a cell are changed in a way that
affects cell height? Does this depend on the type of editor?
Suggestions?
> * It destroys the previously set row height. If the contents of the
cell
> are later modified (or the cell/column is removed), it cannot be restored.
I guess you mean if we, say, scrolled the table and the row height
decreased because the cell with greatest height was not rendered. I
agree that render-time is not the right time to set row height.
Christian Kaufhold - 25 May 2005 17:01 GMT
>> Do you understand why this stuff with overriding setBackground/set-
>> Foreground and invoking super.setBackground/Foreground was done? Is
[quoted text clipped - 7 lines]
> Without it, there is no indication of selection. Is there a different,
> standard way this should be done?
Of course you need to call setBackground/Foreground to set the colors
(taken from the table if you like). But overridding them etc. is confusing
(especially in subclasses) and, in this implemented, does not really work.
Christian
Christian Kaufhold - 25 May 2005 17:05 GMT
>> * It fails unless all renderers agree on a row height. Otherwise the
> row
[quoted text clipped - 8 lines]
>
> The row height shall be equal to the maximum of its cells' heights.
This is not what your code does. That's why it may still cause infinite
relayout.
> Wernitz iterated through all columns in a row to determine the maximum
> height. In a dynamic table, it seems necessary to (re)calculate the
[quoted text clipped - 5 lines]
> to be fired when the contents of a cell are changed in a way that
> affects cell height? Does this depend on the type of editor?
Yes. Yes. Yes. No. There is a catch that you need to make sure to know
whether the table has already updated itself (i.e. received the Table-
ModelEvent) or not - the easiest is to override tableChanged and do it
afterwards or in advance depending on what you want.
>> * It destroys the previously set row height. If the contents of the
> cell
[quoted text clipped - 3 lines]
> I guess you mean if we, say, scrolled the table and the row height
> decreased because the cell with greatest height was not rendered. I
I don't mean that. I mean if, e.g. if contents of the cell with the largest
height are modified so that the height would be smaller, then this
will not cause a decrease of the height.
> agree that render-time is not the right time to set row height.
True.
Christian