Difference between 1.3 and 1.4 in JTable?

java-programmer, Difference between 1.3 and 1.4 in JTable? Hi,

I wrote an application that uses a JTable to display some data. I wrote
my own cellrenderer that provides rows that contain multiple lines of text.
When a row is deleted all other rows are rerendered and the rowheight para-
meter is updated accordingly. This works in 1.3. But in 1.4 (I tried different
JDKs on different platforms (Linux/MacOSX/Windows..) the rowheights are not
updated. Is there a difference in the evaluation of this in 1.4? Maybe that
I have to change the rowheigth at a later point in the program?

Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: email***@***.com
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres

java-programmer >> Difference between 1.3 and 1.4 in JTable? Hello!

Konstantinos Agouros <email***@***.com> wrote:

> I wrote an application that uses a JTable to display some data. I wrote
> my own cellrenderer that provides rows that contain multiple lines of text.
> When a row is deleted all other rows are rerendered and the rowheight para-
> meter is updated accordingly. This works in 1.3. But in 1.4 (I tried different
> JDKs on different platforms (Linux/MacOSX/Windows..) the rowheights are not
> updated. Is there a difference in the evaluation of this in 1.4? Maybe that
> I have to change the rowheigth at a later point in the program?

Maybe.

Maybe you should post some code.

Christian

java-programmer >> Difference between 1.3 and 1.4 in JTable? In <email***@***.com> email***@***.com (Christian Kaufhold) writes:

>Hello!

>Konstantinos Agouros <email***@***.com> wrote:

>> I wrote an application that uses a JTable to display some data. I wrote
>> my own cellrenderer that provides rows that contain multiple lines of text.
>> When a row is deleted all other rows are rerendered and the rowheight para-
>> meter is updated accordingly. This works in 1.3. But in 1.4 (I tried different
>> JDKs on different platforms (Linux/MacOSX/Windows..) the rowheights are not
>> updated. Is there a difference in the evaluation of this in 1.4? Maybe that
>> I have to change the rowheigth at a later point in the program?

>Maybe.

>Maybe you should post some code.
The routine in question is the following:

void resetHeights(JTable jt, int start, int ende)
{
TableModel t;

int defaultrowheight = jt.getRowHeight();
t = jt.getModel();
for(int i=start; i < ende; i++)
jt.setRowHeight(i, defaultrowheight * ((ConsEventTableModel)t).getMaxElementCount(i)+1);
}

This routine is not called by an eventhandler for (like it maybe should be)
the Change of the Datastructure but from the eventhandler from for the button
that causes the changes.

Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: email***@***.com
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres

java-programmer >> Difference between 1.3 and 1.4 in JTable? Konstantinos Agouros <email***@***.com> wrote:
> In <email***@***.com> Roedy Green <email***@***.com> writes:
>
>>On Mon, 04 Aug 2003 20:43:52 GMT, Konstantinos Agouros
>><email***@***.com> wrote or quoted :
>
>>>The routine in question is the following:
>>>
>>> void resetHeights(JTable jt, int start, int ende)
>>> {
>>> TableModel t;
>>>
>>> int defaultrowheight = jt.getRowHeight();
>>> t = jt.getModel();
>>> for(int i=start; i < ende; i++)
>>> jt.setRowHeight(i, defaultrowheight * ((ConsEventTableModel)t).getMaxElementCount(i)+1);
>>> }
>
>>I presume after you do this you fire the appropriate change events to
>>get the table repainted.
> Yup in the routine that calls it:
>
> ((ConsEventTableModel)jt.getModel()).fireTableDataChanged();
> Or do I need to fire something else in 1.4?

Do not call "fireTableDataChanged" from the outside.

The TableModel should be know itself when it changes.

Also, there (obviously) is nothing wrong with the code you *have posted*.

Christian

java-programmer >> Difference between 1.3 and 1.4 in JTable? In <email***@***.com> email***@***.com (Christian Kaufhold) writes:

>Konstantinos Agouros <email***@***.com> wrote:
>> In <email***@***.com> Roedy Green <email***@***.com> writes:
>>
>>>On Mon, 04 Aug 2003 20:43:52 GMT, Konstantinos Agouros
>>><email***@***.com> wrote or quoted :
>>
>>>>The routine in question is the following:
>>>>
>>>> void resetHeights(JTable jt, int start, int ende)
>>>> {
>>>> TableModel t;
>>>>
>>>> int defaultrowheight = jt.getRowHeight();
>>>> t = jt.getModel();
>>>> for(int i=start; i < ende; i++)
>>>> jt.setRowHeight(i, defaultrowheight * ((ConsEventTableModel)t).getMaxElementCount(i)+1);
>>>> }
>>
>>>I presume after you do this you fire the appropriate change events to
>>>get the table repainted.
>> Yup in the routine that calls it:
>>
>> ((ConsEventTableModel)jt.getModel()).fireTableDataChanged();
>> Or do I need to fire something else in 1.4?

>Do not call "fireTableDataChanged" from the outside.

>The TableModel should be know itself when it changes.
Well the question remains is this the right 'fire'?
From the flow of the program the resetHeights method is called after the data
has changed.

Konstantin

>Also, there (obviously) is nothing wrong with the code you *have posted*.
Well I could send You the whole software but I wouldn't want to fill up the
whole group with so many lines...

Konstantin

>Christian
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: email***@***.com
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres

java-programmer >> Difference between 1.3 and 1.4 in JTable? In <email***@***.com> Roedy Green <email***@***.com> writes:

>On Tue, 05 Aug 2003 21:25:13 GMT, Konstantinos Agouros
><email***@***.com> wrote or quoted :

>>Well the question remains is this the right 'fire'?
>>From the flow of the program the resetHeights method is called after the data
>>has changed.
>
>I would think it is, but try a structure change and see if that makes
>it pay attention.
Where do You suggest I call it? In the tablemodel or somewhere else?

Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: email***@***.com
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres

java-programmer >> Difference between 1.3 and 1.4 in JTable?

Konstantinos Agouros wrote:
>
> >Do not call "fireTableDataChanged" from the outside.
>
> >The TableModel should be know itself when it changes.
> Well the question remains is this the right 'fire'?

Depends - always choose the fire that's descibes the change as closely
as possible: if you delete/insert/update individual rows use the
fireDelete/Insert/Update with the appropriate row indices. DataChanged
is for situations when the change is too complex to describe with the
specialized methods.

> From the flow of the program the resetHeights method is called after the data
> has changed.

make sure the table _really_ has updated its internal state before
changing the rowHeight.

>
> >Also, there (obviously) is nothing wrong with the code you *have posted*.
> Well I could send You the whole software but I wouldn't want to fill up the
> whole group with so many lines...
>

and the group (at least me) doesn't want to waste time with speculations
about the code you don't show ... It's time for a small (!) compileable
and runnable example that demonstrates your problem.

Greetings
Jeanette

java-programmer >> Difference between 1.3 and 1.4 in JTable? In <email***@***.com> Kleopatra <email***@***.com> writes:

>Konstantinos Agouros wrote:
>>
>> >Do not call "fireTableDataChanged" from the outside.
>>
>> >The TableModel should be know itself when it changes.
>> Well the question remains is this the right 'fire'?

>Depends - always choose the fire that's descibes the change as closely
>as possible: if you delete/insert/update individual rows use the
>fireDelete/Insert/Update with the appropriate row indices. DataChanged
>is for situations when the change is too complex to describe with the
>specialized methods.

>> From the flow of the program the resetHeights method is called after the data
>> has changed.

>make sure the table _really_ has updated its internal state before
>changing the rowHeight.
That sounds like a clue. How can I ensure that?

Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: email***@***.com
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres