< Zurück | Inhalt | Weiter >

17.3.2 Step 2: Converting the main() Method

The main (pun unintended) changes that need to be made here include allocat- ing the SWT Display, changing from instantiating a JFrame to a Shell, doing away with the Swing “look and feel” stuff (an SWT application always looks like a platform-native application, that’s SWT’s main selling point), and reworking the construction of the GUI. We’ll explain that a little bit later.

For now, we take care of the simple changes. Remember that main() is a static method, so we do not have any nonstatic class members available right

now. The original BudgetPro constructor took a JFrame argument, now it will have to get a Display and a Shell. So we have to allocate a local Display and a local Shell. We also need to add the Display argument to the BudgetPro constructor.

After this is done, we modify the call to the constructor to pass the local

Display and Shell to our class instance.


Next, we have to set a layout manager. The original application used the Swing BorderLayout layout manager. SWT doesn’t have such a critter. Fortunately, the original used only the north, center, and south positions of the BorderLayout. SWT has a simple layout manager called a FillLayout that puts its contained controls in a single row or column, equally sized. Putting the three controls in a column will end up looking much like using the north, center, and south of a BorderLayout. So we change the call to the frame.setLayout() to pass in a new FillLayout and add the SWT.VERTICAL attribute.

The SWT Class

The SWT class is pretty bare-bones. Its primary use is a library of named constants used for attributes to Widget (and other) constructors. You’ll see such SWT.xxxx constants all over your typical SWT application. There are a handful of methods that the SWT class provides, all of them static, including error(), which throws an SWTException, getPlatform(), which returns a string with the name of the platform on which SWT is running, and getVersion(), which returns an int version number.

It also has a subclass, called OLE, which is a Windows-only class that provides ActiveX support for SWT. Obviously, such use is nonportable and non-Linux, so we won’t talk any more about it.

The next block of code in main() sets the Swing look and feel. SWT has nothing like this. All SWT applications look like native applications (we seem to be saying that a lot), so all of this code may be removed.

The next block of code calls methods on the application object (app) that, in the original, construct the three “chunks” of UI and add them to the frame using the BorderLayout attributes. Since, as we explained earlier, all SWT controls must be explicitly joined to a parent control when they are constructed,

the separate create-then-add semantics used in the original will not apply. In the next section, we will walk through converting one of these three create methods. For now, it is enough to know that they will be changed to be meth- ods that return void (no return value) and the calls to add() may be deleted.

That completes the conversion of main().

17.3.3 Step 3: Converting the GUI build() and init()