Section 8 : The java.awt Package
Write
code to implement listener classes and methods, and in
listener methods, extract information from the event
to determine the affected component, mouse position,
nature, and time of the event. State the event
classname for any specified event listener interface
in the java.awt.event package.
Events
Java’s original outward
rippling event model proved to have some shortcomings.
A new Delegation event model was introduced with JDK
1.1. Both models are supported in Java2 but all
methods of old event model are deprecated. The two
models are mutually incompatible. A java program that
uses both models is likely to fail, with events being
lost or incorrectly processed.
The major problem was
that an event could only be handled by the component
that generated that event or by one of the containers
that contained the generating component. This
restriction violated one of the fundamental principals
of OOP: functionality should reside in the most
appropriate class. Often the most appropriate class
for handling an event is not a member of the
originating component’s containment hierarchy.
Another drawback of the
original model was that a large number of CPU cycles
were wasted on uninteresting events. An event in which
a program had no interest would ripple all the way
through the containment hierarchy, before eventually
being discarded. The original model provided no way to
disable processing of irrelevant events.
In the event delegation
model, a component may be told which object or objects
should be notified when the component generates a
particular type of event. If a component is not
interested in an event type, then events of that type
will not be propagated.
The event
class hierarchy
The top most super class
of all the new event classes is java.util.EventObject
Its most important
method is
Object getSource();
One sub class of
EventObject is java.awt.AWTEvent, which is the super
class of all the delegation model event classes. Again
there is only one method of interest:
int getID(); which
returns ID of the event.
An event’s id is an
int that specifies the
exact nature of the event. The hierarchy is as
follows:
Java.util.EventObject
·
Java.awt.AWTEvent
-
ActionEvent
-
AdjustmentEvent
-
ComponentEvent
-
ContainerEvent
-
FocusEvent
-
InputEvent
-
PaintEvent
-
WindowEvent
-
ItemEvent
-
TextEvent
The InputEvent super
class has a long getWhen() method that returns
the time when the event took place.
Event Listeners
An event listener is an
object to which a component has delegated the task of
handling a particular kind of event. When the
component experiences input, an event of the
appropriate type is constructed and passed as the
parameter to a method call on the listener. A listener
must implement the interface
that contains the event handling method. The standard
formula for giving an action listener to a component
is:
-
Create a
listener class that implements the appropriate
interface.
-
Construct
the component.
-
Construct
an instance of listener class.
-
Call
addTypeListener() on the component, passing in the
listener object.
A component may have
multiple listeners for any event type. There is no
guarantee that listeners will be notified in the order
in which they were added. There is also no guarantee
that all listener notification will occur in the same
thread; thus listeners must take precautions against
corrupting shared data.
An event listener may be
removed from a component’s list of listeners by
calling a removeXXXListener() method, passing in the
listener to be removed.
Listener interfaces and their methods
ActionListener
AdjustmentListener
ComponentListener
-
ComponentHidden (ComponentEvent)
-
ComponentMoved (ComponentEvent)
-
ComponentResized (ComponentEvent)
-
ComponentShown (ComponentEvent)
ContainerListener
-
ComponentAdded (ContainerEvent)
-
ComponentRemoved (ContainerEvent)
FocusListener
-
FocusGained (FocusEvent)
-
FocusLost
(FocusEvent)
ItemListener
KeyListener
-
KeyPressed (KeyEvent)
-
KeyReleased (KeyEvent)
-
KeyTyped
(KeyEvent)
MouseListener
-
MousePressed (MouseEvent)
-
MouseReleased (MouseEvent)
-
MouseClicked (MouseEvent)
-
MouseEntered (MouseEvent)
-
MouseExited (MouseEvent)
MouseMotionListener
-
MouseMoved (MouseMotionListener)
-
MouseDragged (MouseMotionListener)
TextListener
WindowListener
-
windowActivated (WindowEvent)
-
windowClosed (WindowEvent)
-
windowClosing (WindowEvent)
-
windowDeactivated (WindowEvent)
-
windowDeiconified (WindowEvent)
-
windowIconified (WindowEvent)
-
windowOpened (WindowEvent)
Explicit event enabling
There is an alternative
to delegating a component’s events. It is possible to
sub class the component and override the method that
receives events and dispatches them to listeners. For
example, Components that originate action events have
a method called processActionEvent (ActionEvent),
which dispatches its action events to each action
listener.
Class MyButton
extends Button{
Public MyButton(String label){
super(label);
enableEvents(AWTEvent.ACTION_EVENT_MASK);
}
public void processActionEvent(ActionEvent ae){
System.out.println(“Processing an action event”);
super.processActionEvent(ae);
}
}
The AWTEvent class
defines 11 constants that can be used to enable
processing of events. Event processing is
automatically enabled when event listeners are added,
so if you restrict yourself to the listener model. You
never have to call enableEvents(). The call to super
class’s version is responsible for calling
actionPerformed() on the button’s action listeners.
Without this call, action listeners would be ignored.
You van also make a
component sub class handle its own events, by making
the sub class an event listener of itself. The only
difference between this strategy and the
enableEvents() strategy is the order in whicg event
handlers are invoked. When you explicitly call
enableEvents(), the component’s processActionEvent()
method will be called before any action listeners are
notified. When the component sub class is its own
event listener, there is no guarantee as to order of
notification.
Each of the 11 listener
types has a corresponding XXX_EVENT_MASK constant
defined in the AWTEvent class, and corresponding
processXXXEvent() methods.
The strategy of
explicitly enabling events for a component can be
summarized as follows:
-
Create a
subclass of the component
-
In the
subclass constructor call
enableEvents(AWTEvent.XXX_EVENT_MASK)
-
Provide
the subclass with a processXXXEvent() method. This
method should call the superclass’ version before
returning.
Methods
protected final void
enableEvents (long eventsToEnable)
This method enables the
events defined by the specified mask, to be delivered
to this component. It only needs to be invoked by
subclasses of Component which desire to have the
specified event types delivered to processEvents()
regardless of whether or not a listener is registered.
protected void
processEvent (AWTEvent e)
it processes events
occurring on this Component. By default this method
calls the appropriate process<type>Event() for the
given class of event.
Process<type>Event
(TypeEvent e)
Processes <type>Events
occurring on this component by dispatching them to any
registered listeners. This method is not called
automatically unless <type>event is enabled for this
component; either by registering a listener or by
enableEvents().
Various
add<type>Listener methods
Methods
|
Defined in
|
addActionListener |
Button |
List |
TextField |
MenuItem |
addAdjustmentListener |
Scrollbar |
|
|
|
addComponentListener |
All components |
|
|
|
addContainerListener |
Container |
|
|
|
addFocusListener |
All components |
|
|
|
addItemListener |
Checkbox |
Choice |
List |
checkboxMenuItem |
addKeyListener |
All components |
|
|
|
addMouseListener |
All components |
|
|
|
addMouseMotionListener |
All components |
|
|
|
addTextListener |
TextComponent |
|
|
|
addWindowListener |
Window |
|
|
|
section8-1-1 | section8-1-2 | section8-1-3 | section8-2
Sections :
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 |