lecture16B

Lecture 16

Announcements
Questions about Frogger Lab
More AWT event handling
Panels and Layout Managers
Other AWT components

Announcements

Computer Club Meeting 6 PM in Wright 5 - Speakers Dan Perry and Mark DeGroote

Handling Choice Events

We talked about event handling for Scrollbar and Button components. Now what about our drop-down menu, the Choice component?

Demo: Boxball using Choice

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.

Component Placement

Default Layout

The default WindowController layout lets us put things in the NORTH, SOUTH, EAST, WEST, and CENTER. Using only that, we are pretty limited. Suppose we wanted to do our Boxball version with buttons using only those positions, keeping in mind that the CENTER is already taken by our canvas.

Demo: Boxball Using Goofy Buttons

Not very nice.. We have already seen one way to get around this...

Panels

Demo: Boxball Using Buttons

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.

Suppose we want our buttons on the EAST side of the window:

Demo: Boxball Using Stacked Buttons

Here, we see an example of a Panel using a different Layout Manager. In this case, a GridLayout. The GridLayout is passed as a parameter to the Panel and tells it that we would like components placed in this panel to be arranged in a grid with 3 rows and 1 column.

Summary of layout managers:

GridLayout was seen above. Arranges components in a grid with the specified number of rows and columns.

BorderLayout is the default for our WindowController. It allows you to place components at the four compass points and in the CENTER.

FlowLayout places the components across the container left to right as they are added, "wrapping around" to a new line when needed. You can specify a FlowLayout to arrange components to be left- or right-justified or to be centered.

Demo: Text Play with a Grid Layout

Demo: Text Play with a Resizeable Panel

In the first demo, there are a number of components, and they are always displayed in a 3 ×1 grid layout, with the text field on top, the font selection menu and hide/show text button in the middle, and the font sizer and current font size label on the bottom. This layout is fixed by the Panel with the 3 ×1 grid layout, with the bottom two rows also being Panels that contain two components each, arranged with the (default) flow layout.

The second demo uses a SizeablePanel that contains all of our components. We are letting that one component control the layout, so when we resize the window, the components get rearranged. If we make it just a regular Panel, it doesn't quite do what we want - we can't see all of the components. So we have an ObjectDraw class SizeablePanel that is a special Panel that can display using multiple rows and still fit on the screen. The Panel version is doing the same rearranging, we just can't see it because most of it is happening off the bottom of our window.

These examples also use components we have not seen yet:

Font - for use with other components such as the next two we list here.

Label - a lot like our Text objects from ObjectDraw.

TextField - editable field of text. Limited to one line.

Plus the now-familiar Button, Scrollbar, and Choice components.

Other AWT Components

There are other components. You can learn more from Slack Appendix B, from the AWT/GUI Cheat Sheet handout and web page, and on the Java/AWT documentation on the Sun web site.

A few of the more popular components we haven't seen yet.

Checkbox - check off "true or false" - can be independent or part of a radio box in which exactly one among a group of checkboxes can be checked at any time.

Demo: Boxball using Radio box and a button

Demo: Boxball using Radio box only

TextArea - editable field of text. Can have multiple lines.

MenuBars, Menus and MenuItems - the familiar menus like "File" and "Edit" and others.

Even better: Swing components - enhanced versions of many AWT components. The bad news: we probably won't use them here. The good news: if you know how to use the regular AWT stuff, you can easily adapt that knowledge to Swing.