Moving to JDK 1.1: Using the delegation event model to create custom AWT components
Learn how a move to JDK 1.1 affects the way you create custom components
Although many applications currently require JDK 1.0.2, a transition to 1.1 is inevitable for any serious development efforts.
This move introduces significant changes to the Abstract Windowing Toolkit (AWT), some of which we'll address in this article.
Over the next few virtual pages, we'll step through the how-tos of building reusable AWT components that operate within the
new event delegation model. The concepts we cover also will be helpful when you need to update existing custom components
to work within the new event model. Those with an eye to the future should make an effort to be aware of the additional changes
JDK 1.2 will bring, but that's another story....
To keep things simple, we're going to look at a fairly basic example. My goal is to show you how to acquire, process, and
dispatch events, without getting bogged down by the complicated color selection details.
The ColorPicker interface
As you can see in the figure below, the ColorPicker component consists of three regions: The left-hand region displays a swatch
of colors, with the red level varying from left to right across the swatch and the green level varying from top to bottom.
The user selects red and green levels by clicking in this swatch. The middle region displays a vertical bar of blue. The user
specifies the amount blue by clicking on the proper location in the bar. The right-hand region displays the current color,
which is a combination of the red, green, and blue levels the user selects. Clicking in this region selects the current color,
causing an appropriate AWT event to occur.
The ColorPicker interface
New AWT essentials
The following list includes the essential elements of the AWT that are affected by JDK 1.1, as they apply to custom components:
- Event model -- Events do not percolate up the container hierarchy as before; instead, interested listeners register themselves
with AWT components, and events are multicast through
- Event types -- A single monolothic
Event class is no longer used for the delivery of all events; instead, different event classes are derived from
java.util.EventObject (or, with respect to the AWT,
java.awt.AWTEvent) and provide an appropriate interface to the relevant occurrence.
- Event methods -- Events are no longer delivered to components through the traditional
handleEvent() method; instead, a
processEvent() method is used along with various associated helpers.
- Event masks -- Event masks of the events that a particular component should generate are now maintained. This new approach
is more efficient because a particular event will not be generated and processed if no target is listening for it. As a result,
if you subclass a component, then it will, by default, not generate the usual AWT events. If you wish to receive certain events,
you must explicitly flag those event types that you wish generated.
- Method names -- Many methods have been renamed to achieve a more consistent and Beans-like interface. This change was necessary
for a transition to the new event model.
The ColorPicker implementation
Here are the four classes that implement our component: