Agenda

• Announcements
• Test Program
• More AWT - event handling

Announcements

• Frogger continues.

  Where were you in 1982? Check out: Froggy's Lament Lyrics and Froggy's Lament Sound Clip

• Don't forget your code reviews. Again these should be painless and hopefully helpful. Please bring your graded lab printouts with you!

Test Program

• You have until next Friday at 4 PM to complete the three test programs.
• Be sure to read everything carefully. Try the demos. Make your programs match their behavior exactly.
• These three programs combine to form 20% of your course grade.
• Honor code reminders: these programs are to be treated as take-home exams. Allowable reference materials are listed on the handout. You may consult only your text, your own notes, your own lab work, and the on-line examples and web pages for our class. You may not discuss the test programs with anyone except the instructors. The TAs can help only with network or computer problems.

  We don't want to deal with honor code cases, and neither do you, so don't do anything that might be considered a violation. Everyone will be much happier.

  If there's any doubt in your mind about consulting a source for the test programs, don't do it! If you think it might be OK, check with one of the instructors first.

AWT

Last time, we saw how the AWT library makes it easy to write programs with nice, interactive user interfaces. This library provides classes to create components, which are things like buttons, scrollbars and menus.

Recall the 4 steps to use an AWT component:

1. Construct a component
2. Add it to the display
3. Write an event handler
4. Assign the event handler to the component

We looked at the first two steps for scrollbars, menus and buttons. Now on to the rest.

Handling Scrollbar Events

Start with Scrollbars again.

Demo: Boxball using a Scrollbar

Our third step was to write an event handler. In this case, it is the adjustmentValueChanged method at the bottom of Boxball.

• We want this method to be called every time someone moves our Scrollbar. Any program response to a change in the Scrollbar happens here.
• It takes one parameter, of type AdjustmentEvent, but our method doesn't actually use it. We will see examples that do. We have to provide the parameter anyway, since (just like our mouse events when we don't actually use the Location point) Java expects that the parameter will be there.
• The Scrollbar includes an accessor method getValue that returns the current "value" of the scrollbar based on its position. This value corresponds to a line position, so we set the new line height to this value.
• Setting the box width is a bit more complicated, since the return value of getValue corresponds to the line height, not to the box size. However, we can compute a reasonable box size based on this. Note that we could just as well have created the Scrollbar to produce values corresponding to box widths and computed line heights based on that. Or even have the scrollbar's values range in some otherwise meaningless range (say, 0 to 100) and compute both a line height and box width from that.

Finally, we need to tell our Scrollbar to report its move events to our adjustmentValueChanged method.

To do this, we call the Scrollbar's addAdjustmentListener method and pass it an instance of a class that contains the adjustmentValueChanged method. Here, we pass it this, since it is our window controller class that contains the adjustmentValueChanged method.

The addAdjustmentListener method certainly isn't expecting a class of type Boxball or even a WindowController. In fact, it wants to be passed something of type AdjustmentListener.

AdjustmentListener is an interface.

Sun Java Docs: AdjustmentListener interface

In order to pass in our Boxball class as the parameter to addAdjustmentListener, we have to make Boxball implement the AdjustmentListener interface. (It does.)

Here, the class that implements AdjustmentListener also happens to be the class that created our Scrollbar and everything else. This is not always the case, and any class that implements AdjustmentListener can be used.

Summary of the steps for the Scrollbar example:

• Construct it. (new Scrollbar();)
• Add it to the display. (add)
• Write the event handler adjustmentValueChanged in a class that implements the AdjustmentListener interface.
• addAdjustmentListener to inform the scrollbar of the event handler.

Handling button events

Next we consider how to handle events from our buttons.

Demo: Boxball using Buttons

The basic idea is the same as in the Scrollbar example.

• We tell each Button about its event handler class using the method addActionListener.
• Again we pass in the class that will contain the event handler, this time the one that includes method actionPerformed and implements ActionListener.

In the Scrollbar event handler, the adjustmentValueChanged method, we didn't use the parameter that was passed in.

What kind of information might we get in that parameter?

The event handlers we wrote previously received a Location that told us the location of the mouse when the particular event occurred.

Since the same event handler can be used for multiple components, it would be good to know which component caused the event. With the scrollbar, this wasn't important since we knew there was just the one scrollbar. But we have multiple buttons, and all will share the event handler in our Boxball class.

It turns out that the parameters to AWT event handlers can be used to find out which component generated the event.

All of the event handlers we'll use have a parameter of a type that implements the EventObject interface. This interface includes a method getSource that returns the source of the event.

Given all of this, we can look at the actionPerformed method of our boxball game with buttons. Basically, we just call getSource on the event passed in, see which button caused the event, and act accordingly.

Handling Choice Events

Now what about our drop-down menu, the Choice component?

Demo: Boxball using Buttons

What information needs to be obtained when the user makes a selection in the Choice component? We need to know which component was used and we need to know which entry was selected.

In our case, the first part is easy - since we have only the one Choice component. We need only determine which entry was selected.

The setup is the same, though a different interface is used to capture the appropriate event types:

• We have our window controller class implement ItemListener.
• We tell the Choice component to report its events to this with a call to addItemListener.
• We write a method itemStateChanged, which takes a parameter of type ItemEvent, as required by the ItemListener interface.

So we know that itemStateChanged will be called when the user makes a selection from our Choice component.

The Choice has a method, much like the Scrollbar's getValue method, that returns its state to us. getSelectedItem returns a String containing the text label of the menu item that is currently selected.

Given that, we compare it to the three strings we placed in the Choice when we created it to find out what action to take.

An important side note here about the comparison of Strings. We will look at Strings in more detail in a few weeks, but note that we don't compare them using == like we use for numbers. We must call the method equals to decide if two strings are equivalent.

A Few More Notes about Component Placement

• The Canvas is a component

  It is placed in the CENTER for you automatically.

• Panels

  We saw briefly that the three buttons from the boxball with buttons example needed to be placed in an intermediate container called a Panel. Our panel in that example was placed in the SOUTH, and the buttons allowed to migrate to their own positions from within it.

• Layout Managers

  If we don't like the way the Panel arranges our buttons (or other components), we can give it more guidance. See Slack's Appendix B for more details.