Go backward to Methods for Handling Events
Go up to Top
Go forward to Images

Interface Components

One could use the drawing primitives associated with the pen and the mouse related event handling methods to build applets that interacted with users through buttons, menus, scrollbars, et cetera. A button, for example could be displayed using "frameRect" and "drawString". Appropriate code in the body of the "mouseDown" method could then enable your applet to react appropriately when a user clicked in the button.

Fortunately, there is a better way to build applets with such user interfaces. The Java language comes with a group of pre-defined methods for constructing user interface components called the "Abstract Windowing Toolkit" or AWT. In JavaTools, I have incorporated some additional facilities designed to make the AWT just a bit easier to use.

As an example of the facilities this makes available, you can add a button labeled "START" to the display area of your applet by executing the instruction:

add( new Button("START"));

Then, to specify how to react when the mouse is clicked in the button, you simply define an event handling method named "buttonClick". Whenever your user clicks on the START button, the instructions in the body of "buttonClick" will be executed. Like the mouse event handling methods, "buttonClick" and other component event handling methods can request additional information through parameters to deal with more complex situations (like an applet with several different buttons that might be clicked).

In addition, Java provides methods that can be used to modify or control the behavior of user interface components. For example, the method "setLabel" can be used to change the text displayed in our exaple "START" button to "STOP". To use such a method, one must associate the component to be affected with a variable name when it is created. Then, this name is later used to make it clear which component is to be the target of the modification request.

We have seen that Java requires a programmer to make it clear what sort of information a name will refer to when we have defined parameter names like "int x". Each kind of component is recognized as a distinct "class" of object by Java and the name of this class must be provided when defining a variable name that will refer to the such an object. Button values all belong to the class of objects called "Button". So, to define a name "startOrStop" that can refer to a button, we would say:

Button startOrStop;

If we wanted to associate our "START" button with the name "startOrStop", we would replace the single instruction shown to add a button to an applet above with the two instructions:

startOrStop = new Button("START");
add(startOrStop);

The first of these instructions actually creates the button (within the computer's memory) and associates it with the name "startOrStop". You should notice that the name "Button" used to identify the class of buttons when declaring variable names is also used as the name of a special constructor method in this instruction. This is not a coincidence. For each class of user interface components Java provides, the name used to describe the class of a variable to be associated with such a component will be the same as the name used as a constructor method when asking that a "new" instance of the component class be created. The second instruction above simply tells Java to add the named button to the Applet's display.

Having associated our button with a name in this way, we could then later say:

startOrStop.setLabel("STOP");

to change the word displayed by the button to "STOP". Of course, later we could say:

startOrStop.setLabel("START");

to put back its original label.

Associating variable names with user interface components is also sometimes essential for the writing of appropriate event handling routines. Suppose that the "startOrStop" button was just one of several buttons included in an applet. Then, when the browser invoked the applet's "buttonClick" routine it would be necessary to determine which button was clicked to determine how to react. To make this possible, the "buttonClick" routine can be defined to expect as a parameter the button that was clicked. If all the buttons in the applet are named, the instructions within the "buttonClick" routine can then ask which of the button's was clicked. For example, in the skeletal method declaration:

void buttonClick( Button whichone) {
	
       if ( whichone == startOrStop ) {
         ... instruction to handle ``START'' or ``STOP'' ...
       } 

	... instructions to handle other buttons ...
}

an "if" structure is used to ensure that the instructions appropriate for a click on the start button are only followed when the button the browser passes to "buttonClick" is the one associated with the name "startOrStop". (In Java, the symbol "==" is used to check if two objects are identical rather than "=" which is used to associate a new object or value with a name.)

In the sections below, we will provide descriptions of each class of user interface component that the AWT and JavaTools provide. In each such section we will explain how to create instances of the component described, how to define appropriate event handling methods for the component and what if any methods are available for controlling the component. Before discussing individual component types, however, there is one more general aspect of the behavior of user interface components to consider.

You may have noticed that neither of the sets of instructions shown above to add a button to an applet includes any specification of where the button should go. How does Java decide where in your applet's screen space to put the button? Like HTML, Java's AWT is based on the assumption that you should not try to control details of the physical layout of your applet (like exactly where a button is positioned). This attitude is based on the fact that you actually don't even have control over what the button or any other component you use will look like. To make users comfortable, Java attempts to display buttons, menus, etc. that are consistent with the interface of the computer from which your applet is viewed. So, the buttons your applet produces on a Mac will look different from those on a Windows machine and different from those on a Unix machine. Of course, they may also have different sizes. Given these variations in the appearance and size of user interface components, trying to control exactly where they appear would be pointless.

Instead of giving you precise control over the placement of user interface components, Java's AWT provides a software component called a layout manager that is responsible for assigning positions to components and then gives you some influence over the behavior of the layout manager. Ultimately, the layout manager decides where things should appear and how big they should be. You, however, have control over aspects of the strategy used (should the screen be divided up into a grid or should components be aligned on the border of the applet's region leaving the center free for a large display area?).

Later, we will provide more information on how to exercise control over the layout manager. Until then, Java's layout manager will display components you add to your applet using a very simple strategy. Just as text is displayed in a word processor or web browser, as you add components to an applet, the AWT will construct a line of components across the top of your applet's display region from left to right. So, if you add a "START" button and then add a "STOP" and later a "PAUSE" button, they will appear across the top of your applet's screen region with "START" on the left, "STOP" in the middle and "PAUSE" on the right.

When a component that you add no longer fits to the right of the last component added, the layout manager starts a new row of components below the first one. The only differences between this strategy and the strategy usually used to fill lines with text are:

The components that form a row within your applet are centered rather than left-justified.
Because there is more variation in component height than in text height, the rows may not look like rows.

So, for now, the only ways you can control the appearance of your applet's display are by the order in which you add components and, in some cases, the size of the components you add.

Now, we are ready to consider the details of individual user interface classes.