JTable listener

[Joan]

JTables are new to me.
How can I add a listener to a JTable
such that when I click on a row it causes
some type of action method to be called.
TIA

 

[pole]

JTables are new to me.
How can I add a listener to a JTable
such that when I click on a row it causes
some type of action method to be called.
TIA

See Sun's tutorial "How to use tables":

http://java.sun.com/docs/books/tutorial/uiswing/components/table.html#selection

pole

 

[Roedy Green]

How can I add a listener to a JTable
such that when I click on a row it causes
some type of action method to be called.

yourTable.getSelectionModel().addListSelectionListener(new
ListSelectionListener() { anonymous class goes here } );

 

[jan V]

How can I add a listener to a JTable

yourTable.getSelectionModel().addListSelectionListener(new
ListSelectionListener() { anonymous class goes here } );

I guess your example was written to be compact for the sake of the hurrying
an answer to the OP, but I think that cascading method calls like your code
does is not a good idea. It's better, IMO, to spread the logic over several
statements. Mainly so that, if you hit a NullPointerException anywhere
within your cascade, you get an unambiguous line reference for the
exception.

I also think having a max of two method calls per line helps readability.

 

[Joan]

See Sun's tutorial "How to use tables":

http://java.sun.com/docs/books/tutorial/uiswing/components/table.html#selection

pole

Thanks a bunch, it looks like this is exactly what I need.
I tried searching sun before but must have been looking in
the wrong place or wrong search criteria.

 

[Raymond DeCampo]

Thanks a bunch, it looks like this is exactly what I need.
I tried searching sun before but must have been looking in
the wrong place or wrong search criteria.

Most of the "how to use xxx" tutorials, where xxx is a GUI widget, is
linked from the javadoc for the GUI widget.

HTH,
Ray

 

[Roedy Green]

I guess your example was written to be compact for the sake of the hurrying
an answer to the OP, but I think that cascading method calls like your code
does is not a good idea.

I have long advocated that programmers should not manually format
programs, the IDE/SCID should do it automatically. see
http://mindprod.com/projects/scid.html Further, every viewer should
have the right to view code in his or her preferred style, even in a
team programming situation.

I have been using Eclipse. I now pay absolutely no heed to formatting
any more, even though Eclipse is still only about 90% of the way there
in terms of what I would like in formatting. Eclipse aggressively
cleans up my code a few minutes later. Unfortunately, that habit of
trusting Eclipse to tidy up has obviously spilled over onto examples
for the newsgroup. I will have to experiment to find some way of
preparing snippets in Eclipse for posting.

About the other issue of splitting out separate temporary variables
for every method call, I disagree, in this particular example, though
I would agree in many other situations.

What I REALLY wanted to say was:

yourTable.addListSelectionListener(new
ListSelectionListener() { anonymous class goes here } );

But Sun does not let me. Presumably to handle complicated cases, they
expose the inner structure of the JTable rather than presenting an
unified facade.

I suggest coding it this way:

yourTable.getSelectionModel().addListSelectionListener
(new ListSelectionListener()
{ anonymous class goes here } );

My code is implying -- that I am just adding a Listener to yourTable.
This gobbledegook about the getSelectetionModel is just what is
required.

If I spell it out as you requested:

ListSelectionModel lm = yourTable.getSelectionModel();
lm.addListSelectionListener(new
ListSelectionListener() { anonymous class goes here } );

There is an implication in the code that the ListSelectionModel has
some importance in its own right. I might reference it again later on
in the code. I might add listeners to some other ListSelectionModel.
I might even change lm's value. It opens up a tiny can of worms that
my version of the code keeps closed. The whole trick of maintainable
code is cutting down on what you have to check.

My version of the code implies that the ListSelectionModel is of no
significance and is used nowhere else in the program.

Perhaps you don't read the code that way, but when I write code for
myself, that is the implication.

 

[Roedy Green]

It's better, IMO, to spread the logic over several
statements. Mainly so that, if you hit a NullPointerException anywhere
within your cascade, you get an unambiguous line reference for the
exception.

I do it your way when writing code for an unfamiliar or exotic API.
The types of each return help document the code. I also makes it
easier to single step through or analyse stack traces. It gives you
something to dump.

 

[Roedy Green]

Most of the "how to use xxx" tutorials, where xxx is a GUI widget, is
linked from the javadoc for the GUI widget.

And one of the fastest ways to find that is by looking up the
component in the Java glossary or in the "all classes" entry of the
Java glossary.

Once you find them, you can build bookmarks, or learn the pattern so
you can usually guess the URL.