«

Hi Guys,
I've tried to integrate the JScrollPane to the one the the cell in the
JTable.

These are my code I've tried.

================================================== ================
TableColumnModel tcm = table.getColumnModel();
TableColumn destinationColumn;
..
..
..
..


JScrollPane listScrollPane;
listModel = new DefaultListModel();
listModel.addElement("any");
listModel.addElement("1st");
listModel.addElement("dummy1");
listModel.addElement("dummy2");
listModel.addElement("dummy3");
listModel.addElement("dummy4");

list = new JList(listModel);
list.setSelectionMode(ListSelectionModel.SINGLE_SE LECTION);
list.setSelectedIndex(0);
list.addListSelectionListener(this);
list.setVisibleRowCount(5);
listScrollPane = new JScrollPane(list);
destinationColumn.setCellEditor(new DefaultCellEditor(listScrollPane));
// ?????????????????????

================================================== ================

As shown, I created JList and put it in the JScrollPane. Then, I like
to put the JScrollPane into the cell in the JTable.
I know the last line has the syntax error because the
"DefaultCellEditor" cannot have the scrollPane type.
How can I solve the problem??

Thank you in advance.

On 15 Aug 2005 16:52:24 -0700, "Happy Day" <>
wrote or quoted :

>As shown, I created JList and put it in the JScrollPane. Then, I like
>to put the JScrollPane into the cell in the JTable.
>I know the last line has the syntax error because the
>"DefaultCellEditor" cannot have the scrollPane type.
>How can I solve the problem??

My first reaction is surely you are confused. You put JTables in
ScrollPanes not ScrollPanes in table cells. That is what tables are
for, to efficiently scroll through the cells.

If you actually want a tiny cell that scrolls all within itself, while
the whole rest of the table scrolls, you will need to write a custom
cell renderer and custom cell editor for it.

For that, reading a Swing text book will probably help. You need a
basic component that you keep modifying given data.

You might start with a non-scrolling component, and once you get that
working, add the scrolling. Start with a renderer, then tackle the
more difficult editor.

Roedy Green wrote:
> On 15 Aug 2005 16:52:24 -0700, "Happy Day" <>
> wrote or quoted :
>
>
>>As shown, I created JList and put it in the JScrollPane. Then, I like
>>to put the JScrollPane into the cell in the JTable.
>>I know the last line has the syntax error because the
>>"DefaultCellEditor" cannot have the scrollPane type.
>>How can I solve the problem??

[snip]

>
> You might start with a non-scrolling component, and once you get that
> working, add the scrolling. Start with a renderer, then tackle the
> more difficult editor.

Unfortunately a renderer cannot scroll (since it will not receive any
events) - so i'd guess it will have to be an editor only.

BK

Babu Kalakrishnan wrote:
> Roedy Green wrote:
>
>> On 15 Aug 2005 16:52:24 -0700, "Happy Day" <>
>> wrote or quoted :
>>
>>
>>> As shown, I created JList and put it in the JScrollPane. Then, I like
>>> to put the JScrollPane into the cell in the JTable.
>>> I know the last line has the syntax error because the
>>> "DefaultCellEditor" cannot have the scrollPane type.
>>> How can I solve the problem??
>
>
> [snip]
>
>>
>> You might start with a non-scrolling component, and once you get that
>> working, add the scrolling. Start with a renderer, then tackle the
>> more difficult editor.
>
>
> Unfortunately a renderer cannot scroll (since it will not receive any
> events) - so i'd guess it will have to be an editor only.
>
> BK

You could follow the approach used by JTreeTable, and make the cell
always return true for isEditing() (or something along those lines)

i.e. how JTreeTable gets the JTree to open and close . . .

Rogan

Rogan Dawes wrote:
> Babu Kalakrishnan wrote:

>>
>> Unfortunately a renderer cannot scroll (since it will not receive any
>> events) - so i'd guess it will have to be an editor only.
>>
>> BK
>
>
> You could follow the approach used by JTreeTable, and make the cell
> always return true for isEditing() (or something along those lines)
>
> i.e. how JTreeTable gets the JTree to open and close . . .
>

Are you referring to the JTreeTable class that appeared in the "The
Swing Connection" articles ?

With all due respects to the stalwarts who created the example class/es
(Quite a bit of what I've learnt about the Swing library have been from
following their articles), I've always felt that its design was
something of a hack. Everything in its design "improvements" being some
kind of a workaround to what a JTable is inherently incapable of doing.

Haven't followed the progress of this in the past year or so since I was
too busy in other areas of the technology. But unless something has
drastically changed (which I doubt), renderers are still what they were:
transient beings that paint a cell and then disappear - what you see on
screen is only an image of what they painted a while back - the user
cannot interact with them - period.

BK

Babu Kalakrishnan wrote:
> Rogan Dawes wrote:
>
>> Babu Kalakrishnan wrote:
>
>
>>>
>>> Unfortunately a renderer cannot scroll (since it will not receive any
>>> events) - so i'd guess it will have to be an editor only.
>>>
>>> BK
>>
>>
>>
>> You could follow the approach used by JTreeTable, and make the cell
>> always return true for isEditing() (or something along those lines)
>>
>> i.e. how JTreeTable gets the JTree to open and close . . .
>>
>
> Are you referring to the JTreeTable class that appeared in the "The
> Swing Connection" articles ?
>
> With all due respects to the stalwarts who created the example class/es
> (Quite a bit of what I've learnt about the Swing library have been from
> following their articles), I've always felt that its design was
> something of a hack. Everything in its design "improvements" being some
> kind of a workaround to what a JTable is inherently incapable of doing.
>
> Haven't followed the progress of this in the past year or so since I was
> too busy in other areas of the technology. But unless something has
> drastically changed (which I doubt), renderers are still what they were:
> transient beings that paint a cell and then disappear - what you see on
> screen is only an image of what they painted a while back - the user
> cannot interact with them - period.
>
> BK

Sure, it seems like a hack to me, too. I don't think that there have
been any adjustments to the source in the last couple of years, at least.

Effectively, what I see as the key "trick" here is this snippet from
AbstractTreeTableModel.java (possibly resulting from some hackery of my
own, but still):

/** By default, make the column with the Tree in it the only
editable one.
* Making this column editable causes the JTable to forward mouse
* and keyboard events in the Tree column to the underlying JTree.
*/
public boolean isCellEditable(Object node, int column) {
return getColumnClass(column) == TreeTableModel.class;
}

Which effectively makes the TreeTable use an editor all the time, I
think, rather than a renderer.

Rogan