< Zurück | Inhalt | Weiter >

Methods

Lest you believe that this means the application is ready to run, just try compiling what you have. Got a few errors yet, don’t we?

Let’s walk through converting the createStatus() method and its relat- ed methods. We’ll then briefly discuss converting the createList() and createButtons() concentrating on the details of the unique UI widgets used in each.


17.3.3.1 Converting the GUI build() Method

In BudgetPro, the top part of the UI is the status pane. It consists, basically, of three labels. In the original application, this pane is constructed by the createStatus() method. In the original, it returns a Swing Component, which is then placed by calling add() on a container managed by the caller.

In SWT, Widgets must be joined to their containers at construction, so we

must restructure this code a little bit. We create a Group to hold our classes together as a unit. We attach the group directly to the parent Shell by using the member variable frame. We set the layout manager to be RowLayout.

We then populate the Group. First, we add the Up button, which is only enabled when in a subaccount. While SWT does support image buttons, we take the shortcut of using the SWT.ARROW style, bitwise-or’ed with the SWT.UP style. Next, we populate the group with our Labels.

Note a change we will talk about some more below: The listener for the Button object called upton is changed. The method is renamed from addActionListener() to addSelectionListener(). Event handling in SWT is similar to Swing/AWT, but not identical, as we will see when we go over the rewrite of the actual event handler code a little later on.

These are the only changes we make to this method.




CAUTION

If a Composite has no layout manager, each Widget in the Composite must have its size and position explicitly set, or else their sizes will default to zero, and they will all be invisible! Tremendous details on SWT layout manager classes can be found in the article “Understanding Layouts in SWT” by Carolyn MacLeod and Shantha Ramachandran on the Eclipse Web site.13


image

17.3.3.2 Converting the GUI init() Method

The setStatus() method is called whenever the data in the core model changes. Its job is to update the UI to reflect those changes. More specifically, it updates the status pane at the top of the UI. There are corresponding methods for the list pane and the button pane.

Oddly, there are no changes in this particular method. The purpose of this method is unchanged. It updates the Labels with the new numbers and checks to see if the current Account is the top level Account. If it is, the Up button is disabled, otherwise it is enabled.

It turns out that all of the methods called on the UI classes in this method have the same names and purposes in Swing and SWT. Don’t assume this will be true in the other cases.


17.3.3.3 Reworking Event Handlers

Finally, in the litany of conversion, we have to modify the event handlers. In this case, the only event of interest is when the Up button is pressed. Pressing a Button produces a Selection event.

In SWT, there are several types of events. Generally, you specify a class that will handle the event by calling one of the add...Listener() methods on the Widget that you wish to process the event for. Examples of these method calls include:

addSelectionListener()

addControlListener()

addFocusListener()

addHelpListener()


image

13. http://www.eclipse.org/articles/Understanding%20Layouts/Understanding%20 Layouts.php


addKeyListener()

addMouseListener()

addMouseMoveListener()

addMouseTrackListener()

addPaintListener()

addTraverseListener()

There are others. SWT naming conventions define an interface for which each add...Listener() method is named. For example, there is a SelectionListener interface. Many such interfaces have multiple methods, each to handle a distinct kind of event; for example, the MouseListener inter- face defines separate methods to handle a button down event, a button release event, and a double-click event. As in Swing, it is common to implement event listeners as anonymous inner classes that implement the listener interface. However, since it is common to be interested only in some (or even only one) listener event, it is annoying to have to implement the full interface, since you have to provide method implementations for every event. For this reason, SWT also provides classes called adapters that implement “do-nothing” methods for every listener event. These also follow a naming convention. For example, the adapter for the MouseListener interface is a class named MouseAdapter; the SelectionListener interface has an adapter named SelectionAdapter, and so on.

For us, this means that we are going to create a reference to an anonymous inner class that implements the SelectionListener interface by extending the SelectionAdapter class. This is probably the weirdest common code construct in Java. Let’s take a direct look at that method (Example 17.2).

If you can correctly answer the following question, then you can be reason- ably assured that you do, in fact, understand what is going on here. Would the program compile and run correctly if the type of the upAction variable were changed to SelectionAdapter? The answer is in the footnote.14


image

14. Yes, it would. The reason is that the addSelectionListener() method takes an argu- ment of type SelectionListener. Both SelectionListener and SelectionAdapter are of that base type. Aren’t Objects wonderful?


image

Example 17.2 The upton Button event listener class reference declaration

private SelectionListener upAction = new SelectionAdapter()

{

public void widgetSelected(SelectionEvent e)

{

// this is the action for UP arrow icon; Account next;

next = current.getParent(); if (next != null) {

current = next; setStatus();

}

}

} ;


image