Skip to main content

JTreeTable: Entire tree is selected after navigating from the last field

8 replies [Last post]
siva
Offline
Joined: 2003-07-15

Hi, I have a JTreeTable with two columns. The first one is for the tree and the second one is for some data. When I use the Tab and navigate field by field, when I reach the last field, the focus goes back to the first row, first column of the table, which is very desirable. However, in doing so, the entire is getting selected. Not sure if this is a bug or I need to code something to prevent it.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rameshgupta
Offline
Joined: 2004-06-04

> Hi, I have a JTreeTable with two columns. The first
> one is for the tree and the second one is for some
> data. When I use the Tab and navigate field by field,
> when I reach the last field, the focus goes back to
> the first row, first column of the table, which is
> very desirable.

That's not the behavior I see. When you reach the last field, hitting tab one more time should take the focus to the *next* row, first field. When you reach the last row, last field, then focus should wrap around to the first row, first field. Is this not what you see?

> However, in doing so, the entire is getting selected.

Sorry, entire *what* is getting selected?

> Not sure if this is a bug or I need to code something to prevent it.

Once I get the clarifications from you, I'll try to answer your question more precisely.

Ramesh

siva
Offline
Joined: 2003-07-15

> > Hi, I have a JTreeTable with two columns. The
> first
> > one is for the tree and the second one is for some
> > data. When I use the Tab and navigate field by
> field,
> > when I reach the last field, the focus goes back
> to
> > the first row, first column of the table, which is
> > very desirable.
>
> That's not the behavior I see. When you reach the
> last field, hitting tab one more time should take the
> focus to the *next* row, first field. When you reach
> the last row, last field, then focus should wrap
> around to the first row, first field. Is this not
> what you see?

Yes, this is what I see and perfect.

> > However, in doing so, the entire is getting
> selected.
>
> Sorry, entire *what* is getting selected?

Ooops, I must have eaten my word. I mean, entire tree.

> > Not sure if this is a bug or I need to code
> something to prevent it.
>
> Once I get the clarifications from you, I'll try to
> answer your question more precisely.
>
> Ramesh

rameshgupta
Offline
Joined: 2004-06-04

> > > Hi, I have a JTreeTable with two columns. The
> > > first one is for the tree and the second one
> > > is for some data. When I use the Tab and navigate
> > > field by field, when I reach the last field,
> > > the focus goes back to the first row, first column
> > > of the table, which is very desirable.
> >
> > That's not the behavior I see. When you reach the
> > last field, hitting tab one more time should take
> > the focus to the *next* row, first field. When you
> > reach the last row, last field, then focus should
> > wrap around to the first row, first field. Is this
> > not what you see?
>
> Yes, this is what I see and perfect.

I am confused :-) Do you see the next row selected or
the entire tree selected?

> > > However, in doing so, the entire is getting
> > > selected.
> >
> > Sorry, entire *what* is getting selected?
>
> Ooops, I must have eaten my word. I mean, entire
> tree.

Sorry, I see only the next row selected. After the last row, the selection wraps to the first row, but the entire tree is never selected!

> > > Not sure if this is a bug or I need to code
> > > something to prevent it.
> >
> > Once I get the clarifications from you, I'll try
> > to answer your question more precisely.
> >
> > Ramesh

Are you sure it is not your code that is causing this problem?

Ramesh

siva
Offline
Joined: 2003-07-15

This seems to happen if the last cell is a display only field. Looks like the default implementation of JTreeTable only allows editing of the tree column and not other columns. So, if we don't override the isCellEditable then this seems to happen. If I override this method and make the second column (I only have two columns, one for tree and another for data) editable, then it works fine.

rameshgupta
Offline
Joined: 2004-06-04

> This seems to happen if the last cell is a display
> only field. Looks like the default implementation of
> JTreeTable only allows editing of the tree column and
> not other columns. So, if we don't override the
> isCellEditable then this seems to happen. If I
> override this method and make the second column (I
> only have two columns, one for tree and another for
> data) editable, then it works fine.

Ever since I fixed issue #49, AbstractTreeTableModel has been unconditionally returning false from isCellEditable(). But I don't see the behavior you mention.

Just for kicks, I changed that to return true always, and still can't reproduce the problem. At this point, may I request you to isolate the problem in a simple reproducible test case, and file a bug report?

Thanks.

Ramesh

siva
Offline
Joined: 2003-07-15

OK, this behavior had always been bugging me and finally
I got a chance to nail it down. Before the call

return applyRenderer(super.prepareRenderer(renderer, row, column),getComponentAdapter()); // adapter row/column should already be set

in JXTreeTable

the row and column of the dataAdapter should be set to the
values passed in the prepareRenderer as done in the
prepareRenderer of JXTable.

Infact, the code has a comment "adapter row/column should already be set" but I don't see that.

bino_george
Offline
Joined: 2003-06-16

Hi Siva,
I was able to reproduce the problem with the FileSystemModel as well as my own TreeTableModel and I think you may be right about the problem. I will look into this today.

Thanks for your analysis,

Regards,
Bino,

bino_george
Offline
Joined: 2003-06-16

Hi Siva,
I did verify that the row/column is not being
set on the ComponentAdapter. Setting it does indeed fix
the problem. I have filed a bug 122 to track it. I also
have included your suggested fix in the bug. I will
probably put your fix back today. Thanks again for the
fix and bug report.

Regards,
Bino.