Confused With Mousemotion Listener And Mouselistener

I'm having a hard time understanding mouse motion listener and mouse listener.

What I know is that it's an interface and it's supposed to be overriden, but what I don't understand is how on earth does each of the methods know what the event just did.

How does method mouseClicked know that the mouse was just clicked and not pressed?

As you can see, well at least to me, there's not telling how given only the passed event. I was expecting something inside the method that would go like:

event.getWhatHappend();

something like that then so you can go on with the rest of the code and say that it was actually pressed or clicked.

public void mouseClicked( MouseEvent event ) {	   statusBar.setText( String.format( "Clicked at [%d, %d]",		event.getX(), event.getY() ) ); } // end method mouseClicked// handle event when mouse pressedpublic void mousePressed( MouseEvent event ){	  statusBar.setText( String.format( "Pressed at [%d, %d]",	  event.getX(), event.getY() ) );} // end method mousePressed

Basically, the component you set the event listener to keeps a track of all events performed to it. Lets start by clicking a ui component...such as a JLabel (I assume you're using swing, but it works the same for awt too). The event handlers built into all ui components extending the java.awt.Component class recognize a new user-invoked event and calls the processEvent method, which determines the type of event has been invoked. In this case, a mouse click I'm suggesting, the processMouseEvent would be called - or if the mouse was dragged across the component, the processMouseMotionEvent would be called.Now, all of this happens, even if you don't set up a listener of your own...it just goes unnoticed. However, when you add a MouseListener object to this JLabel, you're basically requesting that all events received by the processMouseEvent method notify your listener in your class, which in turn enables you to see exactly when a certain type of event is performed.Cool, huh? Hope that helped you

Actually, it would have been impossible to get a mouseClicked event without a mousePressed event. For one, a mouseClick is no more than a mousePressed followed by mouseReleased after a sufficiently small amount of time.In the example code you have given in your post, a mouseClick will result in having the status bar text, very briefly displaying "Pressed at [%d, %d]" before displaying "Clicked at [%d, %d]". Why? For one, a mousePressed event is completed first before a mouseClicked, considering that the former is the first "half" of the latter.Oh, by the way, please be not confused when I used the terms mouseClicked and mousePressed. Those are not actual events; they all use mouseEvent. The difference is only recognizable in the interface function called. Also, for the reason stated above, it is not advisable to define mousePressed and mouseReleased methods in the same class as mouseClicked.I hope that was coherent enough >.<

Actually, it would have been impossible to get a mouseClicked event without a mousePressed event. For one, a mouseClick is no more than a mousePressed followed by mouseReleased after a sufficiently small amount of time.
In the example code you have given in your post, a mouseClick will result in having the status bar text, very briefly displaying "Pressed at [%d, %d]" before displaying "Clicked at [%d, %d]". Why? For one, a mousePressed event is completed first before a mouseClicked, considering that the former is the first "half" of the latter.

Oh, by the way, please be not confused when I used the terms mouseClicked and mousePressed. Those are not actual events; they all use mouseEvent. The difference is only recognizable in the interface function called. Also, for the reason stated above, it is not advisable to define mousePressed and mouseReleased methods in the same class as mouseClicked.

I hope that was coherent enough >.<

What I was asking actually is, how does the computer or whatever it is that works, now that you clicked the mouse and not pressed it?

public void mouseClicked( MouseEvent event ){	   statusBar.setText( String.format( "Clicked at [%d, %d]",		event.getX(), event.getY() ) );} // end method mouseClicked// handle event when mouse pressedpublic void mousePressed( MouseEvent event ){	  statusBar.setText( String.format( "Pressed at [%d, %d]",	  event.getX(), event.getY() ) );} // end method mousePressed

As you can see from above, I am just passing an event without anyway of knowing what the actually happened -- press or click?

Basically, the component you set the event listener to keeps a track of all events performed to it. Lets start by clicking a ui component...such as a JLabel (I assume you're using swing, but it works the same for awt too). The event handlers built into all ui components extending the java.awt.Component class recognize a new user-invoked event and calls the processEvent method, which determines the type of event has been invoked. In this case, a mouse click I'm suggesting, the processMouseEvent would be called - or if the mouse was dragged across the component, the processMouseMotionEvent would be called.
Now, all of this happens, even if you don't set up a listener of your own...it just goes unnoticed. However, when you add a MouseListener object to this JLabel, you're basically requesting that all events received by the processMouseEvent method notify your listener in your class, which in turn enables you to see exactly when a certain type of event is performed.

Cool, huh? Hope that helped you

A bit, but I Still don't understand how the methods know what actually happened -- press or click?
Because, if you come to look at it, you're just passing an event but you don't get any attribute of the the event
in the method?

for instance in

public void mouseClicked( MouseEvent event ){	   statusBar.setText( String.format( "Clicked at [%d, %d]",		event.getX(), event.getY() ) );} 

you have no way of knowing if the user actually clicked the mouse because you don't know what happened.

I was thinking of calling a get method like so:

[b]event.getWhatHappened();[/b]if (event.getWhatHappened == clicked) {mouseClicked();}public void mouseClicked( MouseEvent event ){	   statusBar.setText( String.format( "Clicked at [%d, %d]",		event.getX(), event.getY() ) );} 

get what I mean?

so my question is how does the method know what actually happened?

The method knows what happens because when the event object is generated, that information is provided when the event is created - I can't go into much more detail than that because I honestly don't know how its created.

 

But I can go from a certain level...for example, look at this code from the Component.processEvent method:

 

		if (e instanceof MouseEvent)			switch(e.getID()) {			  case MouseEvent.MOUSE_PRESSED:			  case MouseEvent.MOUSE_RELEASED:			  case MouseEvent.MOUSE_CLICKED:			  case MouseEvent.MOUSE_ENTERED:			  case MouseEvent.MOUSE_EXITED:				  processMouseEvent((MouseEvent)e);				  break;			  case MouseEvent.MOUSE_MOVED:			  case MouseEvent.MOUSE_DRAGGED:				  processMouseMotionEvent((MouseEvent)e);				  break;			  case MouseEvent.MOUSE_WHEEL:				  processMouseWheelEvent((MouseWheelEvent)e);				  break;			}

processEvent, first off, handles the newly generated event. The process of event generation is beyond me just because I never had the interest to find out Anyway, this block determines that the "raw" event is actually a MouseEvent, and it checks to see what type of MouseEvent it is...this, I believe, is what you're asking.

 

To find out the type of AWTEvent is passed, you can get the ID of the event and compare it to some of the constant values in the different event objects, such as MouseEvent, MouseMotionEvent, etc...this ID value is added to the event during initialization, and as each id value is unique to each event type, the processMouseEvent (invoked by the block above) is able to call a certain method from the listener:

 

			int id = e.getID();			switch(id) {			  case MouseEvent.MOUSE_PRESSED:				  listener.mousePressed(e);				  break;			  case MouseEvent.MOUSE_RELEASED:				  listener.mouseReleased(e);				  break;			  case MouseEvent.MOUSE_CLICKED:				  listener.mouseClicked(e);				  break;			  case MouseEvent.MOUSE_EXITED:				  listener.mouseExited(e);				  break;			  case MouseEvent.MOUSE_ENTERED:				  listener.mouseEntered(e);				  break;			}

Now, if you're still asking how the event gets the id during creation, i don't know...but however it obtains it, the id remains constant throughout this process and throughout the api...

 

I hope that helps a bit more now!

Edited August 27, 2006 by BhajunSingh (see edit history)

public void mouseClicked( MouseEvent event ){	   statusBar.setText( String.format( "Clicked at [%d, %d]",		event.getX(), event.getY() ) );} 

you have no way of knowing if the user actually clicked the mouse because you don't know what happened.

 

I was thinking of calling a get method like so:

 

[b]event.getWhatHappened();[/b]if (event.getWhatHappened == clicked) {mouseClicked();}public void mouseClicked( MouseEvent event ){	   statusBar.setText( String.format( "Clicked at [%d, %d]",		event.getX(), event.getY() ) );} 

get what I mean?

 

so my question is how does the method know what actually happened?

 

Actually, you don't really need that. Java is an object-oriented language, not a procedural one. If the method mouseClicked(MouseEvent e) is called, you can be sure that the mouse was, indeed, clicked. The component will never call that method unless the mouse is clicked over it.

 

It's like, "I'm a dentist. People go to me to have their teeth checked. People don't go to me if they wanted to give birth." Quite analogously, "I am a method named mouseClicked. I am automatically called by components I listen to if they are clicked. They will not bother me if the mouse just hovered over them."

 

There is no need to explicitly call mouseListener and mouseMotionListener methods. It is not you who needs to pass the events; the components do it for you. The methods are automatically called by the components that have registered them as a listener. Furthermore, these components know which method to call so there is no need to bother determining whether they actually called the right method. Components never play such horrible pranks.