ActionListener Interface?

[Vasiq Molvizadah]

In the java doc of ActionListener Interface it says:

The listener interface for receiving action events. The class that is interested in processing an action event implements this interface, and the object created with that class is registered with a component, using the component's addActionListener method. When the action event occurs, that object's actionPerformed method is invoked.

In this the object refer to the class who implements the ActionListener interface..then why is that we can't pass the object name in the addActionListener method...why do we have to pass "this" as an argument....

[Maneesh Godbole]

Vasiq Molvizadah wrote:
In this the object refer to the class who implements the ActionListener interface..then why is that we can't pass the object name in the addActionListener method...why do we have to pass "this" as an argument....

I think you are talking about typical examples which have a class implement the ActionListener and in the same class you register the listener. In such scenarios, this refers to the implementing class itself.
However, that is not the only way how you could do it.
You can have another class implement the interface and use an instance of that class to register your listener

class MyListener implements ActionListener
MyListener myListener=new MyListener();
myButton.addActionListener(myListener);

or you can also do it, using anonymous inner classes, like

		JButton button=new JButton("Click me");
		button.addActionListener(new ActionListener() {			
			@Override
			public void actionPerformed(ActionEvent e) {				
				// TODO Auto-generated method stub
			}
		});

or even using the constructor like

		JButton button2=new JButton(new AbstractAction("Click me") {
			
			@Override
			public void actionPerformed(ActionEvent e) {
				// TODO Auto-generated method stub
				
			}
		});

[Vasiq Molvizadah]

Thanks for the explanation buddy....i got it now..

[Maneesh Godbole]

You are welcome.

On a side note, having a class implement the listener is not that a good idea. The code in the books is for illustration purposes only. If you have multiple event sources and a common listener class, you end up with multiple if else statements which can get messy.

In real life, you can follow a simple rule of the thumb.
If you got one source with an unique action, use anonymous inner classes.
If you got multiple sources with the same action, subclass Action/AbstractAction and share that instance with the sources.

This way, your code will be easy to understand and easy to maintain.

[Vasiq Molvizadah]

I got the first point..but really didn't understand the second one...could you please give me an example on the second point....

[Maneesh Godbole]

Consider an application where the user can either choose to shut down using the File->Exit menu or by clicking on the "Exit" button.
So you got two sources, with the same action.

Step 1: Subclass AbstractAction

public class MyExitAction extends AbstractAction {
	
	public MyExitAction(){
		super("Exit");
	}

	@Override
	public void actionPerformed(ActionEvent e) {
		System.exit(0);
	}

}

Then in your code, you share the same exit instance.

MyExitAction exitAction=new MyExitAction();
JMenu exitMenu=new JMenu(exitAction);
JButton exitButton=new JButton(exitAction);

[Vasiq Molvizadah]

But we can also do this with the help of ActionListener Interface...what's so special in extending AbstractAction class....

[Maneesh Godbole]

Please do not unnecessarily quote the whole posts. It makes the page longer and difficult to read. I have edited the quotes from your post. While replying, you can use the reply button.

Action/AbstractAction provides you built in facilities to
1) Set mnemonics
2) Set accelerators
3) Enable/Disable
4) Tooltips

All of these are missing if you use ActionListener.

[Vasiq Molvizadah]

Ok...thanks for the information dude