Event handling

Event handling

Event handling is rather simple. Something occurs and you are notified via a message, "what are you going to do". When the user clicks on the mouse button or presses a key, do you to handle that? If not, let the system use the mouse click, it may want to close the Window.

What each event contains

Three types of event that you'll need/want to handle
  1. Keyboard
  2. Mouse
  3. GUI/Windowing
All events can be handled in the generic handleEvent(Event evt) method, but there are pre-defined methods you can use for the following. The following are equivalent...
public boolean keyDown(Event evt, int key)
{
	Sytem.out.println(key);
	return true;
}

public boolean handleEvent(Event evt)
{
	switch(evt.id)
	{
		case Event.KEY_PRESS:
		{
			System.out.println(evt.key);
			return true;
		}
		default:
			return super.handleEvent(evt);
	}
}
Event handling can occur either in the Container or the Component
i.e
public class MyFrame extends Frame
{
	....
	// WINDOW_DESTROY is caught here
	public boolean handleEvent(Event evt)
	{
		switch(evt.id)
		{
			case Event.WINDOW_DESTROY:
			{
				System.exit(0);
				return true;
			}
			default:
				return super.handleEvent(evt);
		}
	}
	...
}
The second examples extends the Frame to handle WINDOW_DESTROY, instead of re-handling it for every Frame.
class ClosableFrame extends Frame
{
        public boolean handleEvent(Event evt)
        {
                switch(evt.id)
                {
                        case Event.WINDOW_DESTROY:
                        {
                                System.exit(0);
                                return true;
                        }
                        default:
                                return super.handleEvent(evt);
                }
        }
	
}
The handling for Event.WINDOW_DESTROY is now done in the ClosableFrame(the parent) rather than in the Container(child).
public YourFrame extends ClosableFrame
{
	...
}
Albeit it is better to handle events in the Container rather than in the Component, because for every message handled requires an "extended" class. Eventually you'll have excess number of classes to manage. More importantly the above is OK, because Event.WINDOW_DESTROY is handled a uniform manner for most applications. Some applications may want to display a message box stating "Do you want to save your work" instead of just exiting when the user click "closes" the window.

[Q & A's]

Q: If action() is called by both MenuItem and Button how do you know where it really came from?
A: evt.target give you the target of the event. So we must use instanceof
public boolean action(Event evt, Object arg)
{
	// evt.target == java.awt.Button
	if(evt.target instanceof Button)
	{
		if("Start".equals(arg))
		...
		return true;
	}
	// evt.target == java.awt.MenuItem
	else if(evt.target instanceof MenuItem)
	{
		if("Start".equals(arg))
		...
		return true;
	}
	return false;
}

Q: What are all of the ids of the event?
A: They're all documentated in the Event class. Some events such as Event.ACTION_EVENT Event.MOUSE_DOWN, Event. have "callbacks" such as action() and mouseDown(). You can either handle the events in handleEvent() or the "callback", but with the former, you'll need to find out what event occurred first via Event id. The callback knows what h as occurred.

Q: Are there any callbacks for Window messages?
A: No, but this doesn't mean you can't create your own derived class that implements something similar. i.e OnClose()

Q: Doesn't the above mean, you can't really separate interface from implementation(i.e code)?
A: Yes. But as long as you applications or applets are small this is of no concern. Once you reach a certain size you may want to implment your own resource format

Q: Is there a better way that typing all of the "public boolean action(...?
A: Yes. Code generators that generate the skeleton on an event handler which get to you to the 'real' meat of programming. Check out AppletGen

Paint, update and repaint...(section still incomplete)

When your application is covered then uncovered by another AWT object, the GUI then asks you to repaint your Component The methods where this is all handled(override to provide functionality)
  1. paint(Graphics g)
  2. paintAll(Graphics g)
  3. update(Graphics g)
  4. repaint()
What do you actually do in those methods?

Well if you had a piece of graphics drawn in the background that needed to be updated when disturbed(i.e Another window covered it) or some event forces a redraw. For example if you had a clock applet, the clock would need a paint() method. In that paint method you would draw the current time. If it were a digital clock you might want to force a repaint via repaint() every minute. The paint method automatically gets called everytime the clock display is disturbed and needs to be refreshed.

Note: You do not call paint() directly yourself. You also do not need to repaint the entire region, but can repaint sections

In update [More Windowing and Mouse/Keyboard handling to be added]

[Q & A's]

Q: ?
A: Q: ?
A:

[Next] [Prev] [Home]
Nelson Yu
nelson@cs.ualberta.ca
Last modified: Feb 21 1996