8 Das SWT

8 Das SWT 

Das Standard Widget Toolkit stellt eine Anzahl elementarer GUI-Klassen 

zur Verfügung. In diesem Kapitel geben wir zunächst eine Übersicht 

über die Funktionsgruppen des SWT und diskutieren die Vorund 

Nachteile des SWT im Vergleich zu den Java-AWT-Bibliotheken. 

Dann erläutern wir die wichtigsten Funktionsgruppen im Detail. 

Dabei werden wir jedoch keine vollständige API-Beschreibung 

vorlegen. Stattdessen beschränken wir uns auf wesentliche Merkmale 

der einzelnen SWT-Funktionsgruppen und deren Zusammenspiel. Die 

API-Dokumentation der einzelnen SWT-Packages findet man im 

Eclipse-Hilfesystem unter Platform-Plugin Developer Guide>Reference>API 

Reference>Workbench. 

8.1 Übersicht über die SWT-Funktionsgruppen 

Die SWT-Klassen sind auf die folgenden Packages aufgeteilt: 

org.eclipse.swt 

org.eclipse.swt.accessibility 

org.eclipse.swt.awt 

org.eclipse.swt.browser 

org.eclipse.swt.custom 

Dieses Package enthält alle SWT-spezifischen 

Konstanten und Exceptions. Siehe Abschnitt 8.3. 

Dieses Package enthält Klassen für die 

Implementierung behindertengerechter GUIs. 

Siehe Abschnitt 8.14. 

Dieses Package enthält die Klasse SWT-AWT für 

die Einbettung von AWT-Elementen in das SWT. 

Siehe Abschnitt 8.8.1. 

Dieses Package enthält die Klassen für die 

Implementierung des Browser-Widgets. 

Siehe Abschnitt 8.5.14. 

Dieses Package enthält Widgets für die Eclipse- 

Plattform, die nicht direkt auf das Windowing- 

System abgebildet werden können, sondern in 

Java implementiert sind. Siehe Abschnitt 8.5.13. 

147

148 


org.eclipse.swt.dnd 

org.eclipse.swt.events 

org.eclipse.swt.graphics 

org.eclipse.swt.internal 

org.eclipse.swt.layout 

org.eclipse.swt.ole.win32 

org.eclipse.swt.printing 

org.eclipse.swt.program 

org.eclipse.swt.widgets 

8.2 Vor- und Nachteile des SWT 

Die Frage ist natürlich: Wann sollte man das SWT für die Implementierung 

eines GUI verwenden und wann Swing? Im folgenden 

Abschnitt sehen wir uns einige Vor- und Nachteile des SWT im Vergleich 

zu Swing an. 

8.2.1 Vorteile des SWT 

Dieses Package unterstützt Funktionen des 

Datentransfers wie Drag&Drop oder Operationen 

auf die Zwischenablage (Clipboard). 

Siehe Abschnitt 8.10. 

Dieses Package enthält alle SWT-spezifischen 

Klassen (Events) und Interfaces (Listener) für die 

Ereignisverarbeitung. Siehe Abschnitt 8.4.3. 

Dieses Package enthält Klassen für grafische 

Operationen. Siehe Abschnitt 8.7. 

Dieses Package enthält interne SWT-Klassen. 

SWT-Anwendungen sollten nicht direkt auf diese 

Klassen zugreifen, da sich deren API ohne 

Vorwarnung ändern kann. 

Dieses Package enthält verschiedene Layout- 

Klassen für die automatische Positionierung von 

SWT-Elementen. Siehe Abschnitt 8.6. 

Dieses Package unterstützt OLE für 32-Bit- 

Windows-Betriebssysteme. Siehe Abschnitt 8.12. 

Dieses Package unterstützt die Ausgabe auf 

Druckern.Siehe Abschnitt 8.9. 

Dieses Package enthält nur die Klasse program. 

Deren Instanzen repräsentieren Dateiassoziationen 

im zu Grunde liegenden Betriebssystem und 

unterstützen den Start externer Programme. 

Dieses Package enthält alle Widget-Klassen des 

SWT-API. Im Wesentlichen ist es dieses 

Package, das den Funktionsumfang des SWT 

definiert. Siehe Abschnitt 8.5. 

Die Vorteile von SWT liegen in der nahtlosen Einbettung der Applikation 

in die jeweilige Ablaufumgebung. Da die SWT-Widgets nicht – 

wie z.B. das Swing – die nativen Oberflächen emulieren, sondern lediglich 

als Adapter für die entsprechenden Betriebssystemdienste wirken, 

lassen sich mit dem SWT programmierte Benutzeroberflächen vom 

Endanwender praktisch nicht von den Oberflächen nativer Applikationen 

unterscheiden. Ein Button sieht unter Windows 2000 genauso

8.2 Vor- und Nachteile des SWT 

aus wie ein Windows-2000-Button, unter Windows XP genauso wie 

ein Windows-XP-Button und auf dem Mac genauso wie ein Mac-Button. 

Das ist unter Swing oft nicht gegeben. Hier gibt es zwar eine 

Anzahl von vordefinierten Skins, jedoch ist oft nicht das Richtige 

dabei. 

Bei der Ansprechgeschwindigkeit ist Eclipse auch im Vorteil. Das 

SWT unterscheidet sich verständlicherweise auch hier nicht von nativen 

Applikationen, da direkt auf die Ereignisverarbeitung des jeweiligen 

Betriebs- oder Fenstersystems aufgesetzt wird. Swing ist dagegen 

in der Interaktion oft etwas träge. Zudem ist SWT nicht so ressourcenhungrig 

wie Swing. 

Da die Eclipse-Plattform selbst mit Hilfe des SWT programmiert 

ist, ist das SWT natürlich auch die beste Wahl, wenn man Eclipse-Plugins 

entwickeln und GUI-Elemente der Eclipse-Plattform für das Plugin 

nutzen will. 

Last but not least: Da SWT-Widgets direkt auf die entsprechenden 

Dienste des nativen Windowing-Systems aufsetzen, darf erwartet werden, 

dass das SWT sich robuster und toleranter gegenüber der verwendeten 

Hardware und gegenüber verschiedenen Grafikeinstellungen 

verhält als das AWT. Tatsächlich habe ich unter Windows festgestellt, 

dass SWT-Applikationen auch dort noch problemlos liefen, wo AWToder 

Swing-Applikationen auf Grund von DirectX-Inkompatibilitäten 

die Maschine zu einem jähen Halt brachten. 

8.2.2 Nachteile des SWT 

Allerdings gibt es beim SWT gegenüber dem AWT auch einige Nachteile: 

! Zunächst laufen mit dem SWT realisierte Anwendungen nur auf 

den Plattformen ab, für die auch ein SWT implementiert wurde. 

Das sind zurzeit vor allen Dingen die verschiedenen Windows- 

Plattformen (einschließlich Windows CE), Linux mit den Fenstersystemen 

GTK und Motif (einschließlich 64-Bit-GTK auf AMD64), 

verschiedene Unix-Derivate (Solaris, QNX, AIX und HP-UX) und 

Mac OS X. 

! Im Großen und Ganzen sind die verschiedenen Implementierungen 

des SWT funktional äquivalent, aber bekanntlich steckt der Teufel 

im Detail. So gibt es einzelne Funktionen, bei denen das Verhalten 

von Dialogelementen auf den verschiedenen Plattformen voneinander 

abweicht. Plant man, ein Softwareprodukt für den Einsatz auf 

mehreren Plattformen zu entwickeln, ist es unbedingt erforderlich, 

das Produkt auf allen Plattformen gründlich zu testen. 

Bessere Interaktion 

Robuster 

149

150 


! Im Gegensatz zu dem AWT erfordert das SWT eine explizite Ressourcenverwaltung. 

So benutzt das SWT für Bilder, Farben und 

Fonts Betriebssystemressourcen, die, sobald sie nicht mehr benötigt 

werden, mit dispose() wieder explizit freigegeben werden sollten. 

Wir werden die Ressourcenverwaltung ausführlich in Abschnitt 

8.9 diskutieren. 

8.3 Das Package SWT 

Im Package org.eclipse.swt sind lediglich drei Klassen definiert: SWT, 

SWTException und SWTError. Während die beiden letzteren Klassen der 

Fehlerbehandlung (abfangbare bzw. nicht abfangbare Ausnahmebedingungen) 

dienen, sind in der Klasse SWT alle SWT-spezifischen Konstanten 

zusammengefasst. Dazu gehören Konstanten für die Bezeichnung 

von Tasten, für vordefinierte Farben, für Layout-Variationen bei 

den Widgets, für Textstile, Cursorvariationen, Mausaktionen, vordefinierte 

Knöpfe und anderes. 

So bezeichnet z.B. SWT.LINE_DASHDOT eine Strich-Punkt-Linie, oder 

SWT.MouseDoubleClick ein Mausdoppelklick-Ereignis. Wir werden in 

den folgenden Beispielen einige dieser Konstanten im Einsatz sehen. 

8.4 Ereignisse 

Ereignisse bilden den grundlegenden Mechanismus, mit dem Anwendungen 

mit dem GUI kommunizieren. Applikationen registrieren 

Zuhörerinstanzen (Listener) mit den Widgets, um auf Ereignisse reagieren 

zu können. Meistens von Benutzeraktionen wie z.B. Mausklicks 

oder Tastaturbetätigungen hervorgerufen, informieren die Ereignisse 

über die Listener die Anwendung über die Art der Aktion. 

Das Package org.eclipse.swt.events enthält drei verschiedene 

Gruppen: Listener-Interfaces, Event-Klassen und Adapter-Klassen. Bei 

den Ereignissen unterscheiden wir zwischen zwei Kategorien – typisierten 

Ereignissen wie ControlEvent oder MouseEvent und generischen 

Ereignissen (Event). Entsprechend setzt sich diese Aufteilung auch bei 

den Listener-Interfaces fort. 

8.4.1 Zuhörer 

Für jede Ereignisart gibt es verschiedene Listener-Klassen. So kann 

man z.B. einer Taste (Button) mit addSelectionListener() eine SelectionListener-Instanz 

hinzufügen. Wird die Taste selektiert (angeklickt), 

wird die widgetSelected()-Methode dieser SelectionListe-


ner-Instanz aufgerufen. Die Methode erhält als Argument eine 

SelectionEvent-Instanz, die das Ereignis repräsentiert. 

Beispiel: 

public void createButton(Composite parent) { 

Button myButton = new Button(parent, SWT.PUSH); 

myButton.addSelectionListener(new SelectionListener() { 

public void widgetSelected(SelectionEvent e) { 

System.out.println("Button pressed!"); 

} 

public void widgetDefaultSelected(SelectionEvent e) { 

} 

}); 

} 

Hier haben wir für einen neu erzeugten Button eine innere anonyme 

SelectionListener-Klasse als Zuhörer definiert. 

Zu jeder Methode add...Listener() gibt es natürlich auch eine 

Methode remove...Listener(). Insbesondere in komplexen Systemen 

sollten Komponenten, die sich bei anderen Komponenten als Zuhörer 

registrieren, auch wieder mit remove...Listener() abmelden, wenn sie 

deaktiviert werden. So kann überflüssiger Overhead vermieden werden. 

Später, wenn die Komponente wieder aktiviert wird, kann sie sich 

ja wieder mit add...Listener() anmelden. 

Genau aus diesem Grund sollte man auch keine Annahmen über 

die zeitliche Reihenfolge beim Aufruf von registrierten Listenern 

machen. Zwar wird intern beim Auftreten eines Ereignisses die Liste 

der Zuhörer sequenziell abgearbeitet, da sich jedoch Komponenten in 

eigener Regie an- und abmelden können, ist es praktisch unmöglich, 

die Übersicht zu behalten, welcher Zuhörer vor oder nach einem anderen 

aufgerufen wird. 

8.4.2 Adapter 

Adapter sind Standardimplementierungen der jeweiligen Interfaces. Sie 

enthalten leere Methoden für jede im Interface definierte Methode. 

Adapter dienen so dem Komfort des Programmierers. Anstatt alle 

Methoden eines Interface komplett implementieren zu müssen, definiert 

man lediglich eine Unterklasse des zugehörigen Adapters und 

überschreibt diejenigen Methoden, die im konkreten Anwendungsfall 

von Interesse sind. 

Im obigen Beispiel hätten wir natürlich auch einen SelectionAdapter 

verwenden und so auf die Angabe der leeren Methode widget- 

DefaultSelected() verzichten können: 

151

152 


public void createButton(Composite parent) { 

Button myButton = new Button(parent, SWT.PUSH); 

myButton.addSelectionListener(new SelectionAdapter() { 


System.out.println("Button pressed!"); 

} 

}); 

} 

8.4.3 Ereignisse 

Alle Ereignisklassen des SWT (bis auf die Klasse Event) sind Unterklassen 

der Klasse TypedEvent, die ihrerseits ein Abkömmling der Klasse 

java.util.EventObject ist. 

Achtung: TypedEvent ist kein Abkömmling von Event! 

Jeder Ereignistyp besitzt eine Anzahl von öffentlichen Feldern, welche 

die spezifischen Daten des jeweiligen Ereignisses enthalten. So besitzt 

z.B. der Typ MouseEvent die Integer-Felder x, y, stateMask und button. 

Auf alle diese Felder kann direkt zugegriffen werden (also ohne eine 

get...()-Methode). Außerdem besitzt jedes TypedEvent noch die 

Methode getSource(), mit der man den Absender des TypedEvent- 

Objekts ermitteln kann. 

Bei der generischen Klasse Event dagegen kann die Art des Ereignisses 

über das Feld type abgefragt werden. Den Absender erhält man 

über das Feld widget. 

8.4.4 Übersicht über Listener-, Adapter- und Event-Klassen 

Listener 

Typisierte Ereignisse 

Ereignis Adapter 

ArmListener 

ControlListener 

DisposeListener 

FocusListener 

ArmEvent 

Tritt auf, wenn ein Widget, z.B. ein Menü, für die 

Selektion vorbereitet wird. Das ist z.B. der Fall, wenn 

die Maus über dieses Element bewegt wird. 

ControlEvent 

Tritt auf, wenn ein GUI-Element bewegt oder in der 

Größe verändert wird. 

DisposeEvent 

Tritt auf, wenn ein Widget entsorgt wird. 

FocusEvent 

Tritt auf, wenn ein GUI-Element den Fokus erhält 

oder verliert. 

– 

ControlAdapter 

– 

FocusAdapter


Listener 

Typisierte Ereignisse 

Ereignis Adapter 

HelpListener 

KeyListener 

MenuListener 

ModifyListener 

MouseListener 

Wird benachrichtigt, wenn die 

Maustasten betätigt wurden. 

MouseMoveListener 

Wird benachrichtigt, wenn der 

Mauszeiger sich bewegt. 

MouseTrackListener 

Wird benachrichtigt, wenn der 

Mauszeiger sich über GUI-Elementen 

bewegt oder über ihnen schwebt. 

PaintListener 

SelectionListener 

ShellListener 

TraverseListener 

TreeListener 

VerifyListener 

Generische Ereignisse 

Listener 

HelpEvent 

Tritt auf, wenn für ein GUI-Element Hilfe angefordert 

wird (z.B. mit F1). 

KeyEvent 

Tritt auf, wenn Tasten der Tastatur betätigt werden. 

– 

KeyAdapter 

MenuEvent 

Tritt auf, wenn Menüs ein- oder ausgeblendet werden. MenuAdapter 

ModifyEvent 

Tritt auf, nachdem Text modifiziert wurde. 

MouseEvent 

Mausereignis. 

MouseEvent 

Mausereignis. 

MouseEvent 

Mausereignis. 

PaintEvent 

Tritt auf, wenn ein GUI-Element neu gezeichnet 

werden muss. 

SelectionEvent 

Tritt auf, wenn ein GUI-Element selektiert wird. 

ShellEvent 

Tritt auf, wenn sich der Zustand einer Shell-Instanz 

ändert (normal, minimiert, maximiert). 

TraverseEvent 

Tritt bei einem Traverse-Ereignis auf, z.B. wenn der 

Benutzer mit TAB auf das nächste Feld geht oder 

wenn die traverse()-Methode aufgerufen wird. 

TreeEvent 

Tritt auf, wenn Baumknoten expandieren oder kollabieren. 

VerifyEvent 

Tritt auf, bevor Text modifiziert wird. Mittels einer 

entsprechenden Zuweisung an die doit-Variable des 

Ereignisobjekts kann die Modifikation verhindert 

werden (Veto). 

Event 

Nicht typisiertes Ereignis innerhalb des SWT. 

Wird von nicht-Widget-Objekten erzeugt. 

– 

MouseAdapter 

– 

153 

MouseTrackAdapter 

– 

SelectionAdapter 

ShellAdapter 

– 

TreeAdapter 

– 

–

154 


8.5 Widgets 

In diesem Abschnitt behandeln wir die verschiedenen GUI-Elemente 

entlang ihrer Vererbungshierarchie (siehe Abb. 8–1), an deren Spitze 

die Klasse Widget steht. Dazu gehören selbstverständlich die unmittelbaren 

Bedienelemente wie Tasten (Button), Textfelder (Text) oder 

Schieberegler (Slider), aber auch Elemente, die der Gruppierung von 

Bedienelementen dienen wie die Klassen Group und Composite. 

Die Klasse Widget 

Alle GUI-Elemente sind Abkömmlinge der abstrakten Klasse Widget. 

Diese Klasse implementiert einige Basismethoden wie dispose() oder 

addDisposeListener(). Bei der Ausführung von dispose() sendet sie 

allen DisposeListener-Instanzen ein DisposeEvent-Objekt. 

Unmittelbarer Abkömmling der Klasse Widget ist die abstrakte 

Klasse Control. Instanzen dieser Klasse repräsentieren fensterbezogene 

GUI-Elemente und korrelieren direkt mit Ressourcen des Betriebsoder 

Fenstersystems. 

Die Klasse Control 

Die Klasse Control kann folgende Event-Typen an die jeweiligen Listener 

schicken: ControlEvent, FocusEvent, HelpEvent, KeyEvent, MouseEvent, 

MouseTrackEvent, MouseMoveEvent, PaintEvent. Dazu stellt Control 

für die Verwaltung der jeweiligen Listener-Typen verschiedene 

add...Listener()- und remove...Listener()-Methoden zur Verfügung. 

Außerdem stellt Control ein reichhaltiges Arsenal von Methoden 

zur Verfügung, mit denen die verschiedenen Eigenschaften der jeweiligen 

GUI-Elemente gesetzt und abgefragt werden können. Insbesondere 

sind die Methoden setVisible() und setEnabled() zu erwähnen, mit 

denen man GUI-Elemente zeigen und verstecken bzw. für die Eingabe 

freigeben oder sperren kann. 

Größe und Position Anfänglich wird die Größe von Control-Instanzen auf einen 

Default-Wert gesetzt. In vielen Fällen ist das die minimale Größe 

(0x0), so dass das entsprechende GUI-Element unsichtbar bleibt. Mit 

der Methode setBounds() kann die Größe der Instanz und auch die 

Position relativ zum übergeordneten Composite (siehe Abschnitt 8.5.4) 

gesetzt werden. Alternativ kann das übergeordnete Composite mit 

einem Layout (siehe Abschnitt 8.6) versehen werden, das sich selbsttätig 

um die Positionierung der im Composite enthaltenen Control- 

Instanzen kümmert. Mit der Methode pack() wird die bevorzugte 

Größe bzw. die aus dem Layout abgeleitete Größe neu berechnet.

Widget 

Abb. 8–1 Die Hierarchie der wichtigsten Widget-Klassen 

8.5.1 Visuelle Übersicht 

8.5 Widgets 

Caret DragSource DropTarget Menu ScrollBar Tracker 

CoolItem 

Item 

Control 

Scale Slider Scrollable ProgressBar Sash Button Label 

CCombo 

List 

Combo 

Text 

CoolBar 

Composite 

Group Toolbar 

TabFolder CTabFolder 

MenuItem TabItem CTabItem 

TableColumn TableItem ToolItem TreeItem TableTreeItem 

Canvas 

Die beste Übersicht über die verschiedenen Widgets des SWT ist in den 

Beispielapplikationen zu Eclipse enthalten. In Abschnitt 1.1 hatten wir 

Table Tree 

Decorations 

Browser 

Shell 

155

156 


Abb. 8–2 Die SWT-Controls-Beispielapplikation besitzt für die verschiedenen nativen 

Widget-Typen jeweils eine eigene Karteikarte. Rechts kann das Widget über Parameter 

konfiguriert werden. Die Namen der Parameter entsprechen den jeweiligen SWT-Konstanten. 

Links werden dann die Ergebnisse gezeigt. Im unteren Bereich können Ereignisse 

protokolliert werden (hier Selektions- und Fokusereignisse). 

ja bereits die Eclipse-Beispieldateien installiert. Jetzt müssen wir nur 

die entsprechende Beispielapplikation starten. Dazu rufen wir die 

Funktion Window>Show View>Other ... auf. Im folgenden Dialog 

wählen wir die Applikation SWT Examples>SWT Controls aus. Diese 

Applikation erscheint dann auch prompt im Fenster rechts unten (siehe 

Abb. 8–2). Damit wir etwas mehr Platz haben, maximieren wir diese 

Applikation mit einem Doppelklick auf den Reiter. 

Da diese Applikation die verschiedenen Widgets ganz hervorragend 

visualisieren kann, werden wir in den folgenden Abschnitten auf 

die Abbildung einiger Widgets verzichten. Eine weitere Beispielappli-

8.5 Widgets 

kation Custom Controls liefert eine Übersicht über die nicht-nativen 

Widgets (siehe Abschnitt 8.5.13). Beide Applikationen erlauben Ihnen 

außerdem mit Ereignissen und Listenern zu experimentieren. 

8.5.2 Displays, Shells und Monitore 

Die Klassen Display und Shell bilden die Basis für die Konstruktion 

eines GUI. Dabei repräsentiert Display den GUI-Prozess (oder Thread) 

und Shell die jeweiligen Fenster. 

Display 

Die Klasse Display ist das Verbindungsglied zwischen Java-Applikation 

und Betriebssystem. Jede Applikation mit einem SWT-GUI 

erzeugt mindestens eine Instanz dieser Klasse. Genauer gesagt: Benutzt 

man nur einen einzigen Thread, so ist auch nur eine Display-Instanz 

notwendig. Führt man jedoch GUI-Operationen in mehreren Threads 

aus, so wird für jeden dieser Threads eine eigene Display-Instanz 

erzeugt. Mit der statischen Methode Display.getCurrent() kann man 

die aktive Display-Instanz für den jeweiligen Thread herausfinden. 

Im Unterschied zu AWT und Swing erzwingt das SWT, dass alle 

SWT-Objekte nur von dem Thread benutzt werden dürfen, in dem sie 

erzeugt wurden. Trotzdem ist es möglich, auch unter SWT mit mehreren 

Threads zu arbeiten. Die Klasse Display stellt zu diesem Zweck die 

Methoden syncExec() und asyncExec() zur Verfügung, mit denen 

Runnable-Objekte dem jeweiligen Thread der Display-Instanz zur Ausführung 

übergeben werden können. Wir werden in den folgenden 

Kapiteln noch des Öfteren auf diese Technik zurückgreifen. 

Außerdem besitzt Display Methoden, um GUI-Eigenschaften des 

jeweiligen Betriebssystems abzufragen wie getSystemFont() oder get- 

DoubleClickTime(), und verwaltet die Ressourcen des Betriebssystems. 

Darüber hinaus gibt es Methoden für die Widget-Verwaltung, z.B. 

getActiveShell() oder getFocusControl(). Mit der Methode map() 

können Koordinaten von Punkten oder Rechtecken vom Koordinatensystem 

des einen Control-Elements in das Koordinatensystem eines 

anderen Control-Elements übersetzt werden. 

Eine Display-Instanz erzeugt Ereignisse der Klasse Event (siehe 

Abschnitt 8.4.3) mit dem Typ SWT.Open bzw. SWT.Close. Per Programm 

lassen sich Ereignisse vom Typ KeyDown, KeyUp, MouseDown, MouseUp 

oder MouseMove über die Methode post() erzeugen. So können Benutzeroberflächen 

automatisiert werden. Hier ist ein Beispiel: 

SWT-Thread 

Ereignisse 

157

158 


Shell 

// Fensterkoordinate (100,50) in das Display- 

// Koordinatensystem übersetzen 

Point coord = display.map(shell, null, 100, 50); 

event = new Event(); 

event.type = SWT.MouseMove; 

event.x = coord.x; 

event.y = coord.y; 

display.post(event); 

Die Klasse Shell repräsentiert ein Fenster auf dem Desktop des jeweiligen 

Betriebssystems. Dabei kann eine Shell-Instanz drei verschiedene 

Betriebszustände annehmen: maximiert, normal oder minimiert. Beim 

Wechsel dieser Betriebszustände erzeugen Shell-Instanzen Ereignisse 

vom Typ ShellEvent. 

Achtung: Von Shell dürfen keine Unterklassen gebildet werden. Das merkt man 

allerdings erst bei der Ausführung. Für die Implementierung eigener Fensterklassen 

verwendet man besser die JFace-Klasse Window (siehe Abschnitt 9.2). 

Shell-Typen Es gibt zwei verschiedene Arten von Shell-Instanzen: Top-Level-Shells 

für das Hauptfenster der Applikation und Dialog-Shells, die von anderen 

Shells abhängig sind. Welche Instanzenart erzeugt wird, hängt von 

dem Parameter des Konstruktors ab: Wird eine Display-Instanz übergeben, 

wird eine Top-Level-Shell erzeugt; wird eine andere Shell- 

Instanz übergeben, wird eine Dialog-Shell erzeugt. 

Beim Erzeugen einer Shell kann optional ein Stilparameter mit 

angegeben werden. Dabei können die folgenden SWT-Konstanten 

benutzt werden: 

SWT.NONE Standardfenster, betriebssystemabhängig. 

SWT.BORDER Fenster hat einen Rand (plattformabhängig). 

SWT.CLOSE Fenster hat eine Titelzeile mit einem Button zum Schließen des Fensters. 

SWT.MIN Fenster hat eine Titelzeile mit einem Button zum Minimalisieren des Fensters. 

SWT.MAX Fenster hat eine Titelzeile mit einem Button zum Maximalisieren des Fensters. 

SWT.NO_TRIM Fenster hat weder Titelzeile noch Rand. 

SWT.RESIZE Fenstergröße kann durch Ziehen mit der Maus verändert werden. 

SWT.TITLE Fenster hat eine Titelzeile. 

SWT.SHELL_TRIM 

SWT.DIALOG_TRIM 

Kombination von Stilelementen für das Top-Level-Fenster einer Applikation 

(SWT.CLOSE | SWT.TITLE | SWT.MIN | SWT.MAX | SWT.RESIZE). 

Kombination von Stilelementen für Dialog-Fenster 

(SWT.CLOSE | SWT.TITLE | SWT.BORDER).

8.5 Widgets 

Daneben gibt es noch die Konstanten SWT.APPLICATION_MODAL, SWT. 

MODELESS, SWT.PRIMARY_MODAL und SWT.SYSTEM_MODAL, die das modale 

Verhalten des Fensters bestimmen. Ein modales Fenster, das sich im 

Vordergrund befindet, lässt keine anderen Fenster der Applikation 

bzw. des Systems in den Vordergrund kommen. Ein solches Fenster 

sollte so instrumentiert sein, dass der Anwender das Fenster auch 

schließen kann. 

Wird kein Stilparameter angegeben, so hängt der Standardstil sowohl 

vom Betriebssystem als auch von der Art der Shell ab. So ist z.B. bei 

WindowsCE der Standardstil SWT.NONE. Bei anderen Windows-Versionen 

dagegen ist es SHELL_TRIM bzw. DIALOG_TRIM, je nach Art der Shell. 

Mit der Methode setImage() kann ein Icon spezifiziert werden, 

welches das Fenster repräsentiert, wenn es minimalisiert wird. Üblicherweise 

wird ein solches Icon auch in der Titelleiste gezeigt. Mit der 

Methode setImages() können Icons in verschiedenen Auflösungen 

spezifiziert werden, aus denen sich dann die Plattform für den jeweiligen 

Zweck das beste Icon aussuchen kann. 

Abb. 8–3 Eine Shell mit zwei Buttons (hier unter Windows2000). Die Shell wurde mit 

den Optionen SWT.BORDER, SWT.TITLE, SWT.CLOSE, SWT.MIN und SWT.MAX erzeugt, verfügt 

also über einen erhabenen Rand, eine Titelzeile und Tasten zum Schließen, Minimieren 

und Maximieren. 

Übrigens hat eine Shell nicht notwendigerweise eine rechteckige 

Gestalt. Durch Zuweisen einer Region kann man einer Shell eine beliebige 

Gestalt geben. Zunächst erzeugt man dazu eine Region-Instanz, 

der man dann mit add() Umrisslinien hinzufügt, oder aus der man mit 

subtract() auch wieder Teilbereiche entfernen kann. So kann man 

sogar »löchrige« Regions erzeugen. Mit setRegion() weist man dann 

die Region-Instanz der Shell zu. Wirksam wird eine solche Zuweisung 

aber nur für Shells vom Typ SWT.NO_TRIM. Das bedeutet, dass man für 

diese Shell das Schließen, Verschieben und das Verändern der Größe 

selbst organisieren muss. Abschnitt 10.3 zeigt die Konstruktion einer 

solchen irregulären Shell in der Praxis. 

Um ein erstes Beispielprogramm mit einer Shell zu schreiben, richten 

wir in der Workbench zunächst ein neues Projekt widgets ein und 

legen in diesem Projekt die Klasse widgetTest an. Diesem Projekt sind 

zunächst die SWT-Klassen nicht bekannt. Wir müssen die SWT-Biblio- 

Region 

159 

Die Workbench einrichten

160 


thek als externe .JAR-Datei zum Classpath hinzufügen. Wie das geht, 

ist bereits in Abschnitt 4.10 beschrieben. Die SWT-Bibliothek ist bei 

Windows unter 

\eclipse\plugins\org.eclipse.swt.win32_3.0.0\ws\win32\swt.jar 

zu finden. Unter Linux-GTK benötigt man stattdessen zwei JAR- 

Dateien: 

/opt/eclipse/plugins/org.eclipse.swt.gtk_3.0.0/ws/gtk/swt.jar 

/opt/eclipse/plugins/org.eclipse.swt.gtk_3.0.0/ws/gtk/swt-pi.jar 

Für andere Betriebs- und Fenstersysteme gilt Ähnliches. 1 

Das erste SWT-Programm Wir können nun ein erstes Programm schreiben. Zunächst erzeugen 

wir eine neue Display-Instanz. Dann erzeugen wir eine Top-Level- 

Shell. Dies geschieht, indem man dem Konstruktor die Display-Instanz 

als Parameter übergibt. Im Gegensatz dazu wird dem Konstruktor 

einer Dialog-Shell eine andere Shell als Parameter übergeben. 

import org.eclipse.swt.widgets.Display; 

import org.eclipse.swt.widgets.Shell; 

public class widgetTest { 

} 

public static void main(String[] args) { 

// Display-Instanz erzeugen 

final Display display = new Display(); 

// TopLevel-Shell erzeugen (display als parent) 

final Shell toplevelShell = new Shell(display); 

// Titelzeile setzen 

toplevelShell.setText("TopLevel.Titelzeile"); 

// Shell anzeigen 

toplevelShell.open(); 

// Dialog-Shell erzeugen (toplevelShell als parent) 

final Shell dialogShell = new Shell(toplevelShell); 


dialogShell.setText("Dialog.Titelzeile"); 


dialogShell.open(); 

// Warten bis TopLevel-Shell geschlossen wird 

while (!toplevelShell.isDisposed()) { 

// Prüfen ob Ereignisse warten 

if (!display.readAndDispatch()) display.sleep(); 

} 

} 

1. Je nach Eclipse-Version müssen Sie diese Pfade ggf. anpassen!

8.5 Widgets 

Wichtig ist hier die while-Schleife am Ende des Programms, denn im 

SWT ist der Programmierer für die Organisation der Ereignisschleife 

zuständig. Ohne diese Schleife würde die Benutzeroberfläche »einfrieren«. 

Hier bewirken wir mit der Methode readAndDispatch(), dass die 

Display-Instanz ein anstehendes Ereignis liest und an die entsprechenden 

GUI-Elemente weitergibt. Stehen keine weiteren Ereignisse mehr 

an, legen wir den Thread mit der Methode sleep() schlafen, bis ein 

neues Ereignis eintrifft. 

Nun können wir dieses kleine Programm ausführen. Dazu müssen 

wir eine neue Run-Konfiguration vom Typ Java-Applikation erzeugen. 

Das geschieht in der Run-Konfiguration, die Sie sowieso neu anlegen 

müssen. Rufen Sie also Run>Run ... auf und betätigen Sie die New- 

Taste, um eine neue Konfiguration für eine Java-Applikation anzulegen. 

Als Name geben Sie widgetTest ein, dergleichen unter Main Class. 

Unter Projekt geben Sie widgets ein. 

Allerdings reichen diese Angaben für das erfolgreiche Ausführen 

des Programms noch nicht aus. Das SWT benötigt für die Ausführung 

native Module, deren Ort der Java Virtual Machine noch mitgeteilt 

werden müssen. Der Pfad der entsprechenden Modulbibliothek wird 

in der Run-Konfiguration auf der Seite Arguments unter VM Arguments 

eingegeben. Im Falle von Windows ist der folgende Parameter 

einzugeben: 

-Djava.library.path= 

C:\eclipse\plugins\org.eclipse.swt.win32_3.0.0\os\win32\x86 

Unter Linux-GTK ist es: 

-Djava.library.path= 

/opt/eclipse/plugins/org.eclipse.swt.gtk_3.0.0/os/linux/x86 

Unter anderen Betriebs- bzw. Fenstersystemen finden Sie die Modulbibliothek 

an entsprechender Stelle. 2 

Anschließend dürfen Sie dann wirklich Run drücken, und wenn 

alles gut geht, das neue Fenster bewundern. 

Monitor 

Seit Eclipse 3.0 unterstützt das SWT auch Hardware, bei welcher der 

grafische Arbeitsbereich auf mehrere Monitore verteilt sein kann. Das 

mag zunächst nach Spezialanwendung klingen, ist es aber nicht. So 

sind höherwertige Notebooks oft in der Lage, den Arbeitsbereich auf 

das Notebook-LCD und auf einen externen Monitor zu verteilen. 

2. Je nach Eclipse-Version müssen Sie diese Pfade ggf. anpassen! 

161 

SWT Ablauf-Konfiguration

162 


Eclipse unterstützt diese Hardware mit der SWT-Klasse Monitor. 

Mit der Display-Methode getMonitors() erhält man ein Array der 

angeschlossenen Bildschirme und mit der Methode getPrimaryMonitor() 

erhält man den Primärbildschirm. Insbesondere verfügt die 

Klasse Monitor über die Methoden getBounds() und getClientArea(), 

mit der die Position und Größe des Bildschirms bzw. des nutzbaren 

Bereiches abgefragt werden kann. So gehört z.B. die Windows-Taskleiste 

nicht zum nutzbaren Bereich. 

SWT-Applikationen, welche Dialoge, Menüs usw. positionieren, 

verschieben oder in der Größe verändern, sollten diese Methoden nutzen, 

um z.B. zu erreichen, dass ein Dialog oder ein Menü jeweils nur 

auf dem Primärbildschirm erscheint und nicht auf zwei Bildschirme 

aufgespalten wird. In Abschnitt 10.3 zeigen wir, wie die Klasse Monitor 

in der Praxis angewandt wird. 

8.5.3 Dialoge 

Die Klasse Dialog ist eine abstrakte Klasse, von der konkrete native 

Dialoge abgeleitet werden können. Der dazu notwendige Code folgt in 

etwa diesem Muster: 

public class MyDialog extends Dialog { 

Object result; 

// Konstruktor mit Stilparameter 

public MyDialog (Shell parent, int style) { 

super (parent, style); 

} 

// Konstruktor ohne Stilparameter 

public MyDialog (Shell parent) { 

this (parent, 0); 

// Die Null kann durch eigene Defaultstilparameter ersetzt 

// werden 

} 

public Object open () { 

// Übergeordnete Shell holen (wie im Konstruktor gesetzt) 

final Shell parent = getParent(); 

// Neue Dialog-Shell erzeugen 

final Shell shell = new Shell(parent, SWT.DIALOG_TRIM | 

SWT.APPLICATION_MODAL); 

// Dialogtitel auf Shell-Titel übertragen 

shell.setText(getText()); 

// Hier legen wir alle Widgets an 

// Die Variable result wird üblicherweise in der 

// Ereignisverarbeitung dieser Widgets gesetzt

} 

} 

shell.open(); 

// Warten bis Dialog-Shell geschlossen wird 

final Display display = parent.getDisplay(); 

while (!shell.isDisposed()) { 

if (!display.readAndDispatch()) 

display.sleep(); 

} 

return result; 

8.5 Widgets 

Einige konkrete Unterklassen von Dialog sind allerdings bereits im 

SWT enthalten. Dies sind: 

ColorDialog Dialog zum Auswahl einer Farbe. 

DirectoryDialog Dialog zur Auswahl eines Verzeichnisses im Dateisystem. 

FileDialog 

Das Aussehen und die Funktionsweise all dieser Dialoge hängt natürlich 

vom jeweiligen Betriebssystem ab. Am besten schauen Sie sich die 

verschiedenen Dialoge auf der Seite Dialog in der oben genannten 

Eclipse-Beispielanwendung SWT Controls einmal an. 

Im folgenden Code zeigen wir, wie wir den MessageBox-Dialog in 

einem Beispielprogramm anwenden (siehe Abb. 8–4): 

Vordefinierte Dialoge 

Dialog zur Auswahl einer Datei. Durch Stilparameter kann festgelegt werden, zu 

welchem Zweck die Datei ausgewählt wird: SWT.OPEN und SWT.SAVE. 

FontDialog Dialog zur Auswahl einer Schriftart. 

MessageBox 

PrintDialog 

MessageBox 

163 

Dialog zur Ausgabe einer Mitteilung. Durch Stilparameter kann festgelegt werden, mit 

welchen Knöpfen der Dialog instrumentiert wird. Dabei sind folgende Kombinationen 

möglich: 

SWT.OK 

SWT.OK | SWT.CANCEL) 

SWT.YES | SWT.NO) 

SWT.YES | SWT.NO | SWT.CANCEL) 

SWT.RETRY | SWT.CANCEL) 

SWT.ABORT | SWT.RETRY | SWT.IGNORE) 

Außerdem kann festgelegt werden, welches Icon mit abgebildet wird: 

SWT.ICON_ERROR 

SWT.ICON_INFORMATION 

SWT.ICON_QUESTION 

SWT.ICON_WARNING 

SWT.ICON_WORKING 

Dialog zur Auswahl eines Druckers und für die Druckereinrichtung. Siehe auch 

Abschnitt 8.9.

164 


import org.eclipse.swt.SWT; 

import org.eclipse.swt.widgets.Display; 

import org.eclipse.swt.widgets.MessageBox; 

import org.eclipse.swt.widgets.Shell; 


} 

public widgetTest() { 

super(); 

} 










while (true) { 

// MessageBox erzeugen 

MessageBox box = 

new MessageBox( 

toplevelShell, 

SWT.RETRY 

| SWT.CANCEL 

| SWT.APPLICATION_MODAL 

| SWT.ICON_QUESTION); 

// Titel setzen 

box.setText("Test"); 

// Nachricht setzen 

box.setMessage("Wollen Sie das noch einmal versuchen?"); 

// MessageBox öffnen 

if (box.open() == SWT.CANCEL) 

break; 

} 

} 

Abb. 8–4 Die im Beispiel erzeugte Message-Box unter Windows XP.

8.5 Widgets 

Für eigene, komplexere Dialoge wird man allerdings in der Regel 

anstelle der oben besprochenen SWT-Klasse Dialog die gleichnamige 

JFace-Klasse (siehe Kapitel 9) verwenden, die wesentlich komfortabler 

in der Handhabung ist. Fast alle Dialoge in der Eclipse-Workbench 

bauen auf JFace-Dialogen auf und nicht auf dem SWT-Dialog. 

8.5.4 Composites, Groups und Canvas 

Normalerweise bringt man Widgets auf einer Shell nicht direkt an, 

sondern setzt noch eine oder mehrere Hierarchien von Composite- 

Instanzen dazwischen. Composites dienen dem Gruppieren von Widgets. 

So wird man beispielsweise die Buttons eines Dialogs mit Hilfe 

von Composites zu Gruppen zusammenfassen (besonders wichtig bei 

Radiobuttons, bei denen sich die Buttons innerhalb eines Composites 

gegenseitig auslösen) oder wird mehrere Eingabefelder sowie Labels 

aus Layout- und Navigationsgründen zusammen gruppieren. 

Will man nun Widgets einem Composite hinzufügen, so sucht man 

zunächst vergebens nach einer add()-Methode. Stattdessen werden 

GUI-Oberflächen auf andere Art und Weise konstruiert. Beim Anlegen 

eines neuen Widgets wird das übergeordnete Composite als Parameter 

übergeben, und damit ist das Widget dem Composite zugeordnet. Die 

Anordnung auf dem Composite erfolgt dann in der Reihenfolge, in der 

die einzelnen Widgets erzeugt wurden. 

Da auch Composites Widgets sind, wird auch beim Erzeugen einer 

Composite-Instanz ein übergeordnetes Composite angegeben (auch 

Shells sind Composites). In der Regel wird man wichtige Eigenschaften 

wie Hintergrund- und Vordergrundfarbe sowie Schriftart vom übergeordneten 

Composite übernehmen, wie im folgenden Code gezeigt. 

Auch die Position und Abmessungen des Composite können relativ 

zum übergeordneten Composite angegeben werden. 

// neue Composite-Instanz erzeugen 

final Composite composite = new Composite(parent,0); 

// Eigenschaften von übergeordnetem Composite übernehmen 

composite.setBackground(parent.getBackground()); 

composite.setForeground(parent.getForeground()); 

composite.setFont(parent.getFont()); 

// Position und Abmessungen setzen 

composite.setBounds(X,Y,WIDTH,HEIGHT); 

Optional kann im Konstruktor als zweiter Parameter die Konstante 

SWT. NO_RADIO_GROUP angegeben werden, wenn man Radiobuttons 

gruppieren will, ohne ihr Auslöseverhalten zu beeinflussen. 

Eine Unterklasse der Klasse Composite ist die Klasse Group. Diese 

zeichnet zusätzlich eine Randlinie. Das Aussehen dieser Linie kann mit 

Composites 

Groups 

165

166 


den Stilkonstanten SWT.SHADOW_ETCHED_IN, SWT.SHADOW_ETCHED_OUT, 

SWT.SHADOW_IN, SWT.SHADOW_OUT und SWT.SHADOW_NONE gesteuert werden, 

sofern das Betriebssystem das unterstützt. Mit setText() kann ein 

Titel in die Randlinie hineingesetzt werden. In vielen Fällen ist es günstiger, 

eine Group anstelle eines Composite zu verwenden. Insbesondere 

in komplexen Dialogen erlauben Groups eine bessere Navigation mit 

Hilfe der Tastatur, sind also benutzerfreundlicher für Behinderte (siehe 

auch Abschnitt 8.11). 

Für Composite- und Group-Instanzen, die andere Widgets enthalten, 

kann ein Layout gesetzt werden (siehe Abschnitt 8.6). 

Canvas Die Klasse Canvas ist eine Unterklasse von Composite. Sie ist nicht 

dazu bestimmt, andere GUI-Elemente zu enthalten, sondern dient als 

Zeichenfläche für Grafikoperationen. Insbesondere ist es möglich, auf 

der Grundlage von Canvas mit geeigneten Zeichenoperationen eigene 

GUI-Elemente zu realisieren. 

Außerdem bietet Canvas Unterstützung für eine Schreibmarke an 

(setCaret() und getCaret()). 

8.5.5 Tasten 

Damit kommen wir auch schon zu den Buttons. Dabei gibt es verschiedene 

Spielarten. Welcher Button-Typ von einem Konstruktor erzeugt 

wird, wird über den Stilparameter gesteuert: 

SWT.ARROW 

SWT.CHECK 

SWT.PUSH 

SWT.RADIO 

SWT.TOGGLE 

Button mit einem kleinen Pfeil. Üblicherweise 

verwendet, um kleine Menüs einzublenden. 

Kästchen (Checkbox) zum Ankreuzen. Der 

Text befindet sich neben dem Kästchen. 

Taste mit Beschriftung auf der Tastenfläche. 

Radiobutton. Mehrere Radiobuttons innerhalb 

einer Gruppe lösen sich gegenseitig aus. 

Wie SWT.PUSH, nur dass beim ersten Klick die 

Taste gedrückt bleibt und beim zweiten Klick 

wieder auslöst.

8.5 Widgets 

Daneben gibt es noch Möglichkeiten, das Aussehen und die Ausrichtung 

der Buttons zu beeinflussen: 

SWT.FLAT Der Button wird nicht dreidimensional gezeichnet, sondern »flach«. 

SWT.BORDER Der Button wird mit einem Rahmen umgeben. 

Diese Attribute werden allerdings nicht von allen Plattformen unterstützt. 

Mit den Methoden setText() und setImage() können Buttons mit 

einem Text und einer Grafik versehen werden. Bei den Arten PUSH und 

TOGGLE erscheinen Text und Grafik auf der Fläche des Buttons, bei den 

Arten CHECK und RADIO rechts neben dem Button. Buttons der Art ARROW 

zeigen weder Text noch Grafik an. 

Die beiden Methoden schließen sich gegenseitig aus. Entweder: 

oder: 

final Button button = new Button(composite,SWT.PUSH); 

button.setText("Drück mich!"); 

// Auf Klickereignisse reagieren 

button.addSelectionListener(new SelectionAdapter() { 


System.out.println("Taste wurde gedrückt"); 

} 

}); 

final Button button = new Button(composite,SWT.PUSH); 

Display display = composite.getDisplay(); 

final Image image = new Image(display, "bilder/grafik.gif"); 

button.setImage(image); 


button.addSelectionListener(new SelectionAdapter() { 


System.out.println("Taste wurde gedrückt"); 

} 

}); 

// Bild entsorgen, wenn der Button entsorgt wird 

button.addDisposeListener(new DisposeListener() { 

public void widgetDisposed(DisposeEvent e) { 

image.dispose(); 

} 

}); 

Im zweiten Fall war es notwendig, die Image-Ressource wieder freizugeben, 

sobald sie nicht mehr gebraucht wurde, denn Bilder belegen 

Ressourcen im Betriebssystem. 

Texte und Bilder 

167

168 


Tipp: Eine gute Quelle für Bilder für Buttons, Werkzeugleisten und anderes 

sind die jeweiligen icons-Verzeichnisse der verschiedenen Eclipse-Plugins, 

z.B. \eclipse\plugins\org.eclipse.pde.ui_3.0.0\icons\obj16. 

8.5.6 Schieberegler, Skalen und Fortschrittsbalken 

Slider und Scale 

Die beiden Klassen Slider und Scale dienen der Eingabe eines numerischen 

Werts mittels eines Schiebereglers. Üblicherweise wird Slider 

für die Positionierung von Fensterinhalten verwendet (Scroll), während 

Scale für die Einstellung numerischer Parameter verwendet wird, 

z.B. für Lautstärke, Helligkeit, Kontrast, etc. (Abb. 8–5) 

Abb. 8–5 Slider und Scale, jeweils innerhalb einer Group. 

Die folgenden Stilkonstanten beeinflussen das Aussehen dieser Widgets: 

SWT.HORIZONTAL 

SWT.VERTICAL 

SWT.BORDER 

Horizontale oder vertikale Darstellung 

Skalen werden mit einem Rahmen umgeben. Wirkungslos bei 

Slider. 

Das folgende Beispiel erzeugt einen einfachen Schieberegler: 

final Slider slider = new Slider(composite,SWT.HORIZONTAL); 

// Minimalwert setzen 

slider.setMinimum(0); 

// Maximalwert setzen 

slider.setMaximum(1000); 

// Inkrement für Pfeiltasten setzen 

slider.setIncrement(50); 

// Inkrement für Klick auf Schiebefläche setzen 

slider.setPageIncrement(200); 

// aktuelle Position setzen 

slider.setSelection(500); 

// Größe des Handgriffs setzen

slider.setThumb(200); 

// Auf Schiebeereignisse reagieren 

slider.addSelectionListener(new SelectionAdapter() { 


System.out.println("Schieberegler verstellt: " 

+slider.getSelection()); 

} 

}); 

8.5 Widgets 

Mit entsprechenden get...-Methoden können diese Werte auch abgefragt 

werden. Scale hat die gleichen Methoden, allerdings gibt es hier 

die Methoden setThumb() und getThumb() nicht. 

ProgressBar 

Die Klasse ProgressBar dient zur Darstellung von Fortschrittsbalken. 

Das API ähnelt stark dem der Klasse Slider, allerdings erzeugen ProgressBar-Instanzen 

keine Ereignisse. Außerdem kommen noch zwei 

Stilkonstanten hinzu: 

! SWT.SMOOTH bewirkt, dass der Balken nicht durchbrochen gezeichnet 

wird. 

! SWT.INDETERMINATE bewirkt, dass der Balken endlos durchläuft. 

Hier ist also die Anwendung von setSelection() nicht erforderlich. 

Die Anwendung dieser Klasse in der Praxis ist nicht ganz einfach, da 

der Balken nur aktualisiert wird, wenn die Ereignisschleife nicht blockiert 

ist. 

Scrollable und ScrollBar 

Eine Reihe von Widgets sind von vornherein mit Schiebern ausgestattet, 

und zwar alle Abkömmlinge von Scrollable. Welche Schieber bei 

diesen Widgets aktiv sein sollen, kann mit den Stilkonstanten 

SWT.H_SCROLL und SWT.V_SCROLL gesteuert werden. Die Klasse Scrollable 

benutzt als Schieberegler übrigens nicht Slider-Instanzen, sondern 

Instanzen der Klasse ScrollBar. 

ScrollBar ist im Unterschied zu Slider und Scale keine Unterklasse 

von Control. 

8.5.7 Textfelder und Beschriftungen 

Instanzen der Klasse Text werden benutzt, um Text anzuzeigen, einzugeben 

oder zu verändern (Abb. 8–6). Mit Hilfe von Stilkonstanten 

können Text-Instanzen konfiguriert werden: 

169

170 


SWT.MULTI 

SWT.SINGLE 

Bestimmt, ob das Textfeld mehrere oder nur eine Zeile hat. 

SWT.READ_ONLY Text im Textfeld kann nicht vom Benutzer verändert werden. 

SWT.WRAP Automatischer Umbruch wird unterstützt. 

Abb. 8–6 Das obere Feld ist ein Feld vom Typ Text, das untere ist vom Typ StyledText 

(siehe auch Abschnitt 8.5.13). Für beide Felder wurde die Schriftart Eras Book gesetzt, im 

unteren Feld wurden noch Formatierungen vorgenommen. Außerdem wurde für beide 

Felder eine vertikale Scrollbar gewählt. 

Instanzen der Klasse Text erzeugen folgende Ereignistypen: 


Wenn die Enter-Taste gedrückt wird, wird die SelectionListener- 

Methode widgetDefaultSelected() aufgerufen 

ModifyEvent Nachdem Text verändert wurde. 

VerifyEvent 

Bevor Text verändert wird. Durch Zuweisung des Werts false an 

die Variable doit des Ereignisobjekts kann die Veränderung des 

Textes verhindert werden (Veto). 

Das folgende Beispiel erzeugt ein Textfeld mit einem VerifyListener 

für die Gültigkeitsprüfung: 

final Text text = new Text(composite,SWT.SINGLE); 

text.setText("Eingabetext"); 

text.addSelectionListener(new SelectionAdapter() { 


System.out.println("Enter gedrückt: "+text.getSelection()); 

} 

}); 

text.addModifyListener(new ModifyListener() { 

public void modifyText(ModifyEvent e) { 

System.out.println("Text nach Modifikation: "+text.getText()); 

} 

}); 

text.addVerifyListener(new VerifyListener() { 

public void verifyText(VerifyEvent e) { 

String s = text.getText();

} 

}); 

System.out.println("Text vor Modifikation: "+s); 

// Veto: Eingaben länger als 10 Zeichen verhindern 

if (s.length() >= 10) e.doit = false; 

8.5 Widgets 

Die Klasse Text besitzt ein reichhaltiges Arsenal an Methoden für die 

Texteingabe. Insbesondere gibt es auch Methoden, um Textinhalte mit 

dem systemweiten Clipboard auszutauschen (cut(), copy(), paste()). 

Instanzen der Klasse Label dienen meist dazu, andere Widgets zu 

beschriften. Daneben können Label benutzt werden, um eine Grafik 

bzw. eine horizontale oder vertikale Linie abzubilden. Der jeweilige 

Einsatzzweck und das Aussehen eines Labels können über folgende 

Stilkonstanten beeinflusst werden. 

SWT.SEPARATOR Stellt eine horizontale oder vertikale Linie dar. 



SWT.SHADOW_IN 

SWT.SHADOW_OUT 

SWT.SHADOW_NONE 

SWT.CENTER 

SWT.LEFT 

SWT.RIGHT 

Der folgende Code zeigt die Erzeugung eines Textlabels: 

final Label label = new Label(composite, SWT.NULL); 

label.setText("Eingabe"); 

Bildlabel werden mit der Methode setImage() erzeugt. Wie bei Buttons 

(Abschnitt 8.5.6) sollten Image-Instanzen wieder freigegeben werden, 

wenn sie nicht mehr benötigt werden. 

8.5.8 Tabellen, Listen und Combos 

Stellt Orientierung einer Linie fest. 

Schattendarstellung einer Linie. 

Ausrichtung eines Text- oder Bildlabels. 

SWT.WRAP Automatischer Umbruch bei Textlabels. 

Tabellen und Listen dienen der tabellarischen Darstellung von Inhalten, 

wobei auch die Auswahl von Elementen unterstützt wird. Eine 

Platz sparende Variante für die Listenauswahl sind Combos (Abb. 8–7). 

Beschriftungen 

171

172 



SWT.FULL_SELECTION 


SWT.VIRTUAL 


Abb. 8–7 Von links nach rechts: Tabelle, Liste und Combo. Oben sieht man das Combo 

im Normalzustand, darunter nach einem Klick auf die Pfeiltaste. Bei der Tabelle wurden 

die Gitterlinien und die Kopfzeile sichtbar geschaltet. 

Tabellen 

Die Klasse Table ist für die Darstellung von Tabellen verantwortlich. 

Zusätzlich zu den Composite-Stilkonstanten stehen noch folgende 

Stilkonstanten zur Verfügung: 

Der Benutzer kann nur eine bzw. mehrere Tabellenzeilen auswählen. 

Die gesamte Tabellenzeile ist selektierbar (normalerweise kann nur das erste 

Element selektiert werden). 

Vor jeder Tabellenzeile wird eine Checkbox abgebildet. Der Zustand der Checkbox kann 

mit den Methoden setChecked() und getChecked() gesetzt bzw. abgefragt werden. 

Diese Konstante zeigt eine virtuelle Tabelle an, d.h. eine Tabelle, deren Elemente 

erst erzeugt werden, wenn sie tatsächlich benötigt werden. Damit können sehr große 

Tabellen realisiert werden. Beim Aufbau einer virtuellen Tabelle muss die Anzahl der 

Tabelleneinträge mit der Methode setItemCount() gesetzt werden. Sobald ein neues 

Tabellenelement (TableItem) benötigt wird, wird es von der Tabelle erzeugt. Dann 

wird ein SWT.SetData-Ereignis ausgelöst, wobei das Event-Objekt das neue Tabellenelement 

enthält. Im Listener kann dann das Tabellenelement fertiggestellt werden, 

bevor es dann von der Tabelle zur Anzeige gebracht wird. 

Table-Instanzen erzeugen SelectionEvent-Objekte, wenn ein Tabellenelement 

selektiert wird. Beim SelectionListener wird die Methode 

widgetDefaultSelected() aufgerufen, wenn auf einem Tabellenelement 

Enter gedrückt oder ein Doppelklick ausgeführt wurde. 

Tabellenspalten Zur Konfiguration der einzelnen Tabellenspalten werden jeder 

Tabelle TableColumn-Objekte zugeordnet. Das geschieht auf die gleiche 

Weise, in der Widgets auf einem Composite angebracht werden. Die 

Table-Instanz wird dem TableColumn()-Konstruktor als Parameter

8.5 Widgets 

übergeben. Dann kann man für jedes TableColumn-Objekt noch mit 

setText() eine Spaltenüberschrift und mit setWidth() die Breite in 

Pixeln setzen. 

Die Breite von Tabellenspalten kann vom Benutzer verändert werden. 

Auch sind die Spaltenköpfe als Tasten ausgelegt. Folglich erzeugen 

TableColumn-Objekte eine Anzahl von Ereignissen. Ein ControlEvent 

wird erzeugt, wenn die Tabellenspalte verschoben oder in der 

Größe verändert wird. Ein SelectionEvent wird erzeugt, wenn der 

Spaltenkopf angeklickt wird. 

Die Ausrichtung der Spalten kann durch die Stilkonstanten 

SWT.LEFT, SWT.CENTER und SWT.RIGHT bestimmt werden. Mit der 

Methode showColumn() können wir eine bestimmte Spalte der Tabelle 

in den sichtbaren Anzeigebereich bringen. 

Auf ähnliche Weise werden die Tabellenzeilen als TableItem- 

Objekte erzeugt. Mit der Methode setText() wird der Inhalt der 

Tabellenzeilen gesetzt. Als Parameter kann ein String oder – im Fall 

mehrspaltiger Tabellen – ein Stringarray angegeben werden. Seit 

Eclipse V3 kann man sogar mit setForeground(), setFont() bzw. set- 

Background() die Textfarbe, die Schriftart bzw. Hintergrundfarbe für 

jedes einzelne TableItem setzen. 

Mit den Table-Methoden setHeaderVisible() und setLinesVisible() 

können die Spaltenüberschriften und Trennlinien angezeigt oder 

unterdrückt werden. 

Im folgenden Code erzeugen wir eine Tabelle mit drei Spalten und 

zwei Zeilen: 

final Table table = new Table(composite, 

SWT.SINGLE | SWT.H_SCROLL | 

SWT.V_SCROLL | SWT.BORDER | 

SWT.FULL_SELECTION ); 

// Drei Tabellenspalten erzeugen 

final TableColumn col1 = new TableColumn(table,SWT.LEFT); 

col1.setText("Spalte 1"); 

col1.setWidth(80); 







// Spaltenköpfe und Trennlinien sichtbar machen 

table.setHeaderVisible(true); 

table.setLinesVisible(true); 

// Zwei Tabellenreihen erzeugen 

Tabellenzeilen 

173

174 


Listen 

final TableItem item1 = new TableItem(table,0); 

item1.setText(new String[] {"a","b","c"}); 

final TableItem item2 = new TableItem(table,0); 

item2.setText(new String[] {"d","c","e"}); 

// SelectionListener hinzufügen 

table.addSelectionListener(new SelectionAdapter() { 


processSelection("Enter gedrückt: "); 

} 


processSelection("Tabellenelement ausgewählt: "); 

} 

private void processSelection(String message) { 

// Ausgewählte Tabellenzeilen holen 

TableItem[] selection = table.getSelection(); 

// Wegen SWT.SINGLE ist nur eine Zeile ausgewählt 

TableItem selectedRow = selection[0]; 

// Die einzelnen Tabellenelemente für Ausgabe aufbereiten 

String s = selectedRow.getText(0)+", "+ 

selectedRow.getText(1)+", "+selectedRow.getText(2); 

System.out.println(message + s); 

} 

}); 

Will man lediglich eine einspaltige Liste von String-Elementen zur 

Selektion anbieten, so gibt es mit der Klasse List eine einfachere Möglichkeit. 

List-Instanzen erzeugen die gleichen Ereignisse wie Table- 

Instanzen, jedoch wird die Methode widgetDefaultSelected() nur bei 

einem Doppelklick aufgerufen. Mit den SWT-Konstanten SWT.SINGLE 

und SWT.MULTI kann bestimmt werden, ob nur eine oder aber mehrere 

Listeneinträge selektiert werden können. 

Im folgenden Code bauen wir eine Liste mit drei Einträgen auf. 

Wir erlauben und verarbeiten die Selektion mehrerer Einträge: 

final List list = new List(composite,SWT.MULTI); 

list.add("Element1"); 



list.addSelectionListener(new SelectionAdapter() { 


processSelection("Enter gedrückt: "); 

} 


processSelection("Listeneintrag ausgewählt: "); 

}

private void processSelection(String message) { 

// Ausgewählte Element holen 

String[] selection = list.getSelection(); 

// Für die Ausgabe aufbereiten 

StringBuffer sb = new StringBuffer(); 

for (int i = 0; i < selection.length; i++) { 

sb.append(selection[i]+" "); 

} 

System.out.println(message + sb); 

} 

}); 

Combos 

8.5 Widgets 

Schließlich gibt es noch die Klasse Combo, die Listenauswahl und Texteingabe 

kombiniert. 

Instanzen der Klasse Combo erzeugen folgende Ereignistypen: 


ModifyEvent 

Die folgenden Stilkonstanten beeinflussen die Funktionsweise und das 

Aussehen der Combo-Instanzen: 

SWT.DROP_DOWN 

SWT.READ_ONLY 

Wenn die Enter-Taste gedrückt wird, wird die Selection- 

Listener-Methode widgetDefaultSelected() aufgerufen. 

Wird ein Listenelement ausgewählt, so wird die Methode 

widgetSelected() aufgerufen. 

Wird aufgerufen, wenn Text durch Tastatureingabe oder 

Listenauswahl verändert wird. 

Die Auswahlliste wird erst beim Klick auf die Pfeiltaste 

angezeigt. 

Es ist nur möglich, vorgegebene Werte auszuwählen, jedoch 

nicht, Werte im Textfeld einzugeben. 

SWT.SIMPLE Die Auswahlliste ist immer sichtbar. 

Das folgende Beispiel erzeugt ein solches Combo-GUI-Element: 

final Combo combo = new Combo(composite,SWT.DROP_DOWN); 

// Listenelement erzeugen 

combo.add("Element1"); 



// Vorbelegung des Textfeldes 

combo.setText("Select"); 


combo.addSelectionListener(new SelectionAdapter() { 


175

176 


System.out.println("Enter gedrückt: " + combo.getText()); 

} 


System.out.println("Listeneintrag ausgewählt: " + 

combo.getText()); 

} 

}); 

// ModifyListener hinzufügen 

combo.addModifyListener(new ModifyListener() { 

public void modifyText(ModifyEvent e) { 

System.out.println("Text wurde modifiziert: "+combo.getText()); 

} 

}); 

CCombo Das (nicht native) Widget CCombo ist dem Combo-Widget sehr ähnlich. 

Es kann jedoch auch randlos auftreten und kann so in Tabellenzellen 

angewandt werden. 

8.5.9 Bäume 

Die Klasse Tree ist für die Darstellung von Bäumen verantwortlich 

(Abb. 8–8). Dabei werden die Funktionsweise und das Aussehen des 

Baums durch folgende Stilkonstanten beeinflusst: 




Der Benutzer kann nur eine bzw. mehrere Baumknoten 

auswählen. 

Vor jedem Baumknoten wird eine Checkbox abgebildet. Der 

Zustand der Checkbox kann mit den Methoden setChecked() 

und getChecked() gesetzt bzw. abgefragt werden. 

Abb. 8–8 Zwei Bäume: links nur mit Textknoten; rechts wurden den Textknoten Bilder 

zugewiesen.

Tree-Instanzen erzeugen folgende Ereignistypen: 


TreeEvent 

8.5 Widgets 

Bei einem Doppelklick oder Drücken der Enter-Taste wird 

die SelectionListener-Methode widgetDefaultSelected() 

aufgerufen. 

Wird ein Knoten ausgewählt, so wird die Methode 

widgetSelected() aufgerufen. 

Wird ein Knoten expandiert, wird die Methode treeExpanded() 

der TreeListener-Instanz aufgerufen. Wird ein Knoten 

kollabiert, wird treeCollapsed() aufgerufen. Der entsprechende 

Knoten wird im Feld item des TreeEvent-Objekts 

übergeben. 

Die einzelnen Baumknoten werden als TreeItem-Instanzen erzeugt. 

Dabei wird dem TreeItem()-Konstruktor entweder der Baum oder ein 

anderer Baumknoten als Argument übergeben. Textinhalte für TreeItem-Instanzen 

können mit setText() gesetzt werden, wobei mit set- 

Font() die Schriftart des Textes gesetzt werden kann. Zusätzlich zum 

Text kann mit setImage() jeder TreeItem-Instanz eine Grafik zugeordnet 

werden. Wie bei Buttons (Abschnitt 8.5.6) sollten alle Image-Instanzen 

wieder freigegeben werden, wenn sie nicht mehr benötigt werden. 

Der folgende Code erzeugt einen einfachen Baum mit drei Knoten, 

wobei der erste Knoten zwei Kindknoten hat: 

final Tree tree = new Tree(composite,SWT.SINGLE); 

// Oberste Knotenebene erzeugen 

final TreeItem node1 = new TreeItem(tree,SWT.NULL); 

node1.setText("Knoten 1"); 





// Zweite Knotenebene erzeugen 

final TreeItem node11 = new TreeItem(node1,SWT.NULL); 

node11.setText("Knoten 1.1"); 

final TreeItem node12 = new TreeItem(node1,SWT.NULL); 

node12.setText("Knoten 1.2"); 


tree.addSelectionListener(new SelectionAdapter() { 


System.out.println("Enter gedrückt: " + 

tree.getSelection()[0].getText()); 

} 


System.out.println("Baumknoteneintrag ausgewählt: " + 

tree.getSelection()[0].getText()); 

} 

177

178 


}); 

// TreeListener hinzufügen 

tree.addTreeListener(new TreeAdapter() { 

public void treeCollapsed(TreeEvent e) { 

System.out.println("Knoten kollabiert: " + 

((TreeItem) e.item).getText()); 

} 

public void treeExpanded(TreeEvent e) { 

System.out.println("Knoten expandiert: " + 

((TreeItem) e.item).getText()); 

} 

}); 

Bei größeren Bäumen wird man in der Regel darauf verzichten, den 

Baum gleich komplett aufzubauen. Stattdessen bietet sich hier an, 

Baumknoten erst dann vollständig aufzubauen, wenn sie sichtbar werden, 

also wenn der entsprechende Elternknoten expandiert wird. 

8.5.10 Verschiebbare Trennleisten 

Die Klasse Sash ist für verschiebbare Trennleisten verantwortlich. 

Diese Trennleisten können benutzt werden, um ein Composite in verschiedene 

Bereiche aufzuteilen. Die Trennleiste kann vom Benutzer 

verschoben werden, so dass sich die Größe der Teilbereiche verändert. 

Das verlangt einigen Aufwand an Ereignisbehandlung, da der Sash 

nicht selbst eine Repositionierung der Nachbarelemente vornimmt. 

Sash-Instanzen erzeugen Ereignisse vom Typ SelectEvent. Die Ausrichtung 

einer Trennleiste kann mit den Stilkonstanten SWT.HORIZONTAL 

und SWT.VERTICAL bestimmt werden (Abb. 8–9). 

Anstelle dieser manuellen Methode kann auch die Klasse SashForm 

verwendet werden, um durch verschiebbare Rahmen getrennte Komponenten 

untereinander zu koordinieren (siehe Abschnitt 8.5.13). 

8.5.11 Pultordner 

Die Klasse TabFolder implementiert einen Pultordner, also eine Einheit, 

bei der Seiten über das Anklicken von Reitern ausgewählt werden 

können. Jede TabFolder-Instanz ist ein Composite, das ein oder mehrere 

TabItem-Instanzen enthalten kann. Jedes TabItem-Objekt entsprícht 

einem Reiter, die Beschriftung des Reiters kann mit der Methode set- 

Text() gesetzt werden. Mit setControl() kann jedem TabItem-Objekt 

eine Control-Instanz (z.B. ein Composite) zugeordnet werden. Diese 

wird zur Anzeige gebracht, wenn das entsprechende TabItem-Objekt

8.5 Widgets 

selektiert wird. Die Control-Instanz muss auf dem TabFolder erzeugt 

worden sein (also mit Angabe der TabFolder-Instanz im Konstruktor). 

TabFolder unterstützt lediglich die Stilkonstante SWT.BORDER. 

TabFolder-Instanzen erzeugen SelectionEvents, wenn ein TabItem 

ausgewählt wird. 

Der folgende Code zeigt als Beispiel einen Pultordner mit zwei Reitern: 


import org.eclipse.swt.events.SelectionAdapter; 

import org.eclipse.swt.events.SelectionEvent; 

import org.eclipse.swt.layout.FillLayout; 

import org.eclipse.swt.widgets.*; 









// Shell komplett ausfüllen 

toplevelShell.setLayout(new FillLayout()); 

// Pultordner erzeugen 

TabFolder folder = new TabFolder(toplevelShell, SWT.NONE); 

// Selektionsereignisse protokollieren 

folder.addSelectionListener(new SelectionAdapter() { 


System.out.println( 

"Reiter selektiert: " + ((TabItem) 

(e.item)).getText()); 

} 

}); 

// Pultordner komplett ausfüllen 

folder.setLayout(new FillLayout()); 

Composite page1 = createTabPage(folder, "tab1"); 

// Auf page1 können nun weitere GUI-Elemente angeordnet werden 

// ... 

Composite page2 = createTabPage(folder, "tab2"); 

// Auf page2 können nun weitere GUI-Elemente angeordnet werden 

// ... 



// Ereignisschleife 

while (!toplevelShell.isDisposed()) { 

179

180 


} 

} 

} 

if (!display.readAndDispatch()) 

display.sleep(); 

private static Composite createTabPage(TabFolder folder, 

String label) { 

// Einen Reiter erzeugen und beschriften 

TabItem tab = new TabItem(folder, SWT.NONE); 

tab.setText(label); 

// Einen Composite als Seite erzeugen 

Composite page = new Composite(folder, SWT.NONE); 

// ... und dem Reiter zuordnen 

tab.setControl(page); 

return page; 

} 

CTabFolder Das (nicht native) Widget CTabFolder ist dem TabFolder-Widget recht 

ähnlich, erlaubt jedoch die Positionierung der Reiter (CTabItem) am 

Kopf (SWT.TOP) oder Fuß (SWT.BOTTOM) des Ordners und verwendet Reiter 

mit geschwungenem Umriss. 

8.5.12 Werkzeugleisten und Menüs 

Werkzeugleisten 

Mit der Klasse ToolBar können Werkzeugleisten implementiert werden. 

Jede ToolBar-Instanz ist ein Composite, das ein oder mehrere ToolItem-Instanzen 

enthält. 

Mit den folgenden Stilkonstanten kann das Erscheinungsbild von 

Werkzeugleisten bestimmt werden: 

SWT.FLAT Zweidimensionale statt dreidimensionaler Darstellung. 

Plattformabhängig. 

SWT.WRAP Automatischer Umbruch 

SWT.RIGHT Rechtsbündige Ausrichtung 



Horizontale oder vertikale Ausrichtung 

ToolItem-Instanzen repräsentieren die Tasten auf der Werkzeugleiste. 

Die Art der Taste kann über eine Stilkonstante bestimmt werden:

SWT.PUSH Normale Taste mit sofortiger Auslösung 

SWT.CHECK Arretierende Taste 

SWT.RADIO Radiotaste mit gegenseitiger Auslösung 

SWT.SEPARATOR Passives Element zum Trennen von Tastengruppen 

SWT.DROP_DOWN Normale Taste mit assoziierter Pfeiltaste 

8.5 Widgets 

Die Beschriftung einer Taste wird mit der Methode setText() gesetzt. 

Bildtasten werden mit der Methode setImage() erzeugt. Zusätzliche 

Bilder, mit setHotImage() (für Tasten unter dem Mauszeiger) und set- 

DisabledImage() (für inaktive Tasten) gesetzt, können die verschiedenen 

Betriebszustände der Werkzeugtaste anzeigen. Wie bei Buttons 

(Abschnitt 8.5.6) sollten die jeweiligen Image-Instanzen wieder freigegeben 

werden, wenn sie nicht mehr benötigt werden. Mit setToolTip- 

Text() kann ein Text gesetzt werden, der angezeigt wird, wenn die 

Maus über die Taste bewegt wird. 

ToolItem-Instanzen erzeugen bei Betätigung SelectionEvent-Ereignisse. 

Bei DROP_DOWN-Tasten muss ermittelt werden, ob die Haupttaste 

oder die Pfeiltaste betätigt wurde. Dies kann über die Abfrage 

(event.detail == SWT.ARROW) geschehen. Die Applikation kann dann 

eine Menüliste aufbauen, welche die Auswahl einer Funktion erlaubt. 

Verschiebbare Werkzeuggruppen (CoolBar) 

Mit der Klasse CoolBar können mehrere ToolBar-Instanzen als so 

genannte CoolItems zu verschiebbaren Gruppen zusammengefasst werden. 

Ein gutes Beispiel für eine CoolBar ist die Werkzeugleiste der 

Eclipse-Workbench. Jede einzelne Toolbar-Instanz wird dabei in eine 

CoolItem-Instanz eingebettet. Diese CoolItem-Instanzen werden auf die 

CoolBar platziert und sind dort verschiebbar. Die Zuordnung zwischen 

CoolItem und Toolbar erfolgt mit der Methode setControl(). Dabei 

muss anfänglich für jede CoolItem-Instanz eine minimale Größe gesetzt 

werden. Im zweiten Beispiel dieses Abschnitts zeigen wir, wie das geht. 

Wird für eine CoolItem-Instanz der Stil SWT.DROP_DOWN gesetzt, so 

erscheint ein Pfeilsymbol, wenn in einer Werkzeuggruppe nicht alle 

Werkzeuge abgebildet werden können. Dazu ist allerdings eine entsprechende 

Ereignisverarbeitung mit Aufbau eines Drop-down-Menüs 

zu implementieren, ähnlich wie das für Drop-down-Tasten notwendig 

ist. 

181

182 


Menüs 

Menüs können mit Hilfe der Klasse Menu aufgebaut werden. Mit den 

folgenden Stilkonstanten kann das Erscheinungsbild von Menüs 

bestimmt werden: 

SWT.BAR Menüleiste 

SWT.DROP_DOWN Drop-down-Menü 

SWT.POP_UP Pop-up-Menü 

Menu-Instanzen erzeugen Ereignisse vom Typ HelpEvent und MenuEvent. 

Erscheint ein Menü auf dem Bildschirm, wird die Methode menuShown() 

der MenuListener-Instanz aufgerufen. Verschwindet das Menü, 

wird die Methode menuHidden() aufgerufen. 

MenuItem Die Menüeinträge werden von MenuItem-Instanzen repräsentiert. 

Die Art des Eintrags kann über eine Stilkonstante bestimmt werden: 


Menüeintrag mit Check-Symbol. Bei Betätigung erscheint und 

verschwindet das Check-Symbol wechselweise. 

SWT.CASCADE Menüeintrag für kaskadierende Menüs 

SWT.PUSH Normaler Menüeintrag 

SWT.RADIO Menüeintrag mit gegenseitiger Auslösung 

SWT.SEPARATOR Passive Trennlinie 

Die Beschriftung eines Eintrags wird mit der Methode setText() 

gesetzt. 

MenuItem-Instanzen erzeugen bei Betätigung Ereignisse vom Typ 

SelectionEvent, ArmEvent und HelpEvent. ArmEvents werden ausgelöst, 

wenn der Mauszeiger über den Menüeintrag positioniert wird. 

Will man beispielsweise eine klassische Menüleiste aufbauen, so 

legt man zunächst die Menüleiste selbst als Menu-Instanz vom Typ 

SWT.BAR an. Als übergeordnetes Composite muss dabei die Shell angegeben 

sein, für welche die Menüleiste aufgebaut werden soll. Freilich ist 

dann die Menüleiste noch nicht für diese Shell aktiviert. Dies muss von 

der Shell-Instanz aus geschehen, und zwar mit der Methode setMenu- 

Bar(). Die einzelnen Menütitel werden dann als kaskadierende Menu- 

Item-Instanzen angelegt. Deren Untermenüs werden als unabhängige 

SWT.DROP_DOWN-Menüs unter der Shell-Instanz angelegt und den 

Menütiteln mit setMenu()zugeordnet. 

Das folgende Beispiel zeigt den Aufbau eines einfachen Menüs mit 

einem einzigen Menütitel:

Menüleiste anlegen 

Menu menuBar = new Menu(toplevelShell, SWT.BAR); 

toplevelShell.setMenuBar(menuBar); 

// Menütitel anlegen 

MenuItem fileTitle = new MenuItem(menuBar, SWT.CASCADE); 

fileTitle.setText("File"); 

// Untermenü für diesen Menütitel anlegen 

Menu fileMenu = new Menu(toplevelShell, SWT.DROP_DOWN); 

fileTitle.setMenu(fileMenu); 

// Menüeintrag anlegen 

MenuItem item = new MenuItem(fileMenu, SWT.NULL); 

item.setText("Exit"); 

// Ereignisverarbeitung für Menüeintrag 

item.addSelectionListener(new SelectionAdapter() { 


toplevelShell.close(); 

} 

}); 

8.5 Widgets 

Im nächsten Beispiel erzeugen wir eine CoolBar, die aus zwei verschiebbaren 

Gruppen mit insgesamt fünf verschiedenen Tasten besteht. Darunter 

ist auch eine Drop-down-Taste, in deren Ereignisverarbeitung 

ein Menü mit zwei Einträgen aufgebaut wird. 

// CoolBar erzeugen 

final CoolBar coolbar = new CoolBar(composite, SWT.NULL); 

// ToolBar als Bestandteil der CoolBar erzeugen 

final ToolBar toolbar1 = new ToolBar(coolbar, SWT.NULL); 

// Pushbutton erzeugen 

final ToolItem toolitem1 = new ToolItem(toolbar1, SWT.PUSH); 

toolitem1.setText("Push"); 

toolitem1.setToolTipText("Push button"); 

// Ereignisverarbeitung für pushbutton 

toolitem1.addSelectionListener(new SelectionAdapter() { 



"Werkzeugtaste gedrückt: " + toolitem1.getText()); 

} 

}); 

// Checkbutton erzeugen 

final ToolItem toolitem2 = new ToolItem(toolbar1, SWT.CHECK); 

toolitem2.setText("Check"); 

toolitem2.setToolTipText("Check button"); 

// CoolItem erzeugen 

final CoolItem coolitem1 = new CoolItem(coolbar, SWT.NULL); 

// Die Toolbar diesem Coolitem zuordnen 

183

184 


coolitem1.setControl(toolbar1); 

// Größe der Toolbar berechnen 

Point size = toolbar1.computeSize(SWT.DEFAULT, SWT.DEFAULT); 

// Benötigte Größe des CoolItem berechnen 

size = coolitem1.computeSize(size.x, size.y); 

// auf diese Größe setzen 

coolitem1.setSize(size); 

// Die minimale Breite entspricht der des ersten Buttons 

coolitem1.setMinimumSize(toolitem1.getWidth(), size.y); 

// Zweite ToolBar erzeugen 

final ToolBar toolbar2 = new ToolBar(coolbar, SWT.NULL); 

// Zwei Radiobuttons erzeugen 

final ToolItem toolitem3a = new ToolItem(toolbar2, SWT.RADIO); 

toolitem3a.setText("Radio"); 

toolitem3a.setToolTipText("Radio button a"); 

final ToolItem toolitem3b = new ToolItem(toolbar2, SWT.RADIO); 

toolitem3b.setText("Radio"); 

toolitem3b.setToolTipText("Radio button b"); 

// Separator 

new ToolItem(toolbar2, SWT.SEPARATOR); 

// Drop-down-Menü-Button erzeugen 

final ToolItem toolitem5 = new ToolItem(toolbar2, SWT.DROP_DOWN); 

toolitem5.setText("Drop-down-Menu"); 

// Ereignisverarbeitung für Drop-down-Menü-Button 

toolitem5.addSelectionListener( 

// die Menüerzeugung findet in Klasse DropDownSelectionListener statt 

new DropDownSelectionListener(composite.getShell())); 

// zweiten CoolItem erzeugen, Toolbar zuordnen und Größe setzen 

final CoolItem coolitem2 = new CoolItem(coolbar, SWT.NULL); 

coolitem2.setControl(toolbar2); 

size = toolbar2.computeSize(SWT.DEFAULT, SWT.DEFAULT); 

size = coolitem2.computeSize(size.x, size.y); 

coolitem2.setSize(size); 

coolitem2.setMinimumSize(toolitem3a.getWidth(), size.y); 

Die Klasse DropDownSelectionListener, die für den Menüaufbau 

zuständig ist, ist folgendermaßen definiert: 

class DropDownSelectionListener extends SelectionAdapter { 

private Menu menu; 

private Composite parent; 

public DropDownSelectionListener(Composite parent) { 

this.parent = parent; 

}

8.5 Widgets 

public void widgetSelected(final SelectionEvent e) { 

// Wir erzeugen das Menü, wenn es noch nicht existiert 

if (menu == null) { 

menu = new Menu(parent); 

final MenuItem menuItem1 = new MenuItem(menu, SWT.NULL); 

menuItem1.setText("Eintrag1"); 

// SelectionListener für menuItem1 setzen 

menuItem1.addSelectionListener(new SelectionAdapter() { 

public void widgetSelected(SelectionEvent m) { 

processMenuEvent(e, menuItem1); 

} 

}); 

menuItem1.addArmListener(new ArmListener() { 

public void widgetArmed(ArmEvent m) { 

System.out.println("Maus über Menü-Eintrag 1"); 

} 

}); 

final MenuItem menuItem2 = new MenuItem(menu, SWT.NULL); 

menuItem2.setText("Eintrag2"); 

// SelectionListener für menuItem1 setzen 

menuItem2.addSelectionListener(new SelectionAdapter() { 

public void widgetSelected(SelectionEvent m) { 

processMenuEvent(e, menuItem2); 

} 

}); 

menuItem2.addArmListener(new ArmListener() { 

public void widgetArmed(ArmEvent m) { 

System.out.println("Maus über Menü-Eintrag 2"); 

} 

}); 

} 

// Prüfen, ob die Pfeiltaste gedrückt wurde 

if (e.detail == SWT.ARROW) { 

if (menu.isVisible()) { 

// Ausblenden, wenn Menü bereits sichtbar 

menu.setVisible(false); 

} else { 

// ToolItem und ToolBar aus dem Event auslesen 

final ToolItem toolItem = (ToolItem) e.widget; 

final ToolBar toolBar = toolItem.getParent(); 

// Position und Abmessung des ToolItem 

Rectangle toolItemBounds = toolItem.getBounds(); 

// relative Position auf absolute Position umrechnen 

Point point = 

toolBar.toDisplay( 

185

186 


} 

new Point(toolItemBounds.x, toolItemBounds.y)); 

// Menü positionieren 

menu.setLocation(point.x, point.y + 

toolItemBounds.height); 

// Menü sichtbar machen 

menu.setVisible(true); 

} 

} else { 



"Werkzeugtaste gedrückt: " + toolItem.getText()); 

} 

} 

private void processMenuEvent( 

final SelectionEvent e, 

final MenuItem item) { 

// Text des Menüeintrags holen 

final String s = item.getText(); 

// ToolItem holen 


// Text des ToolItem durch Text des Menüeintrags ersetzen 

toolItem.setText(s); 

// Menü wieder verstecken 

menu.setVisible(false); 

} 

8.5.13 Spezielle Widgets 

Das Package org.eclipse.swt.custom enthält einige weitere Widgets, 

die auf verschiedenen Plattformen nicht als native GUI-Elemente zur 

Verfügung stehen. Deshalb sind alle Widgets in diesem Package reine 

Java-Implementierungen. 

Wir hatten bereits die Widgets CCombo und CTabFolder kennen 

gelernt. In der folgenden Tabelle listen wir einige weitere dieser Widget-Klassen 

auf:

BusyIndicator 

ControlEditor 

PopupList 

SashForm 

StyledText 

TableTree 

TableEditor 

TreeEditor 

TableTreeEditor 

8.5 Widgets 

Hier ist ein Beispiel für die Anwendung der Klasse SashForm. Zwei SashForm-Instanzen 

werden erzeugt, zunächst eine horizontale und dann 

innerhalb dieser eine vertikale. Beide SashForm-Komponenten haben 

List-Widgets als Kindelemente. 

187 

Diese Klasse dient dazu, den Mauszeiger als Tätigkeitssymbol (Sanduhr etc.) darzustellen. 

Dazu wird die Methode showWhile(display, runnable)verwendet, wobei der zweite Parameter 

vom Typ java.lang.Runnable sein muss. In dessen run()-Methode muss die komplette 

Verarbeitung ausgeführt werden; währenddessen wird das Tätigkeitssymbol angezeigt. 

Mit dieser Klasse kann einem Composite ein anderes GUI-Element zugeordnet werden. 

Wird das Composite verschoben oder in der Größe verändert, so verändert sich ggf. auch 

die Position des zugeordneten Elements. Üblicherweise verwendet man ControlEditor, um 

einem nicht editierfähigen Composite GUI-Elemente für die Eingabe von Werten zuzuordnen. 

Die Eclipse-API-Referenzdokumentation enthält ein Beispiel, in dem einer Canvas- 

Instanz (siehe Abschnitt 8.7) ein Button zugeordnet wird, bei dessen Betätigung die Hintergrundfarbe 

der Zeichenfläche geändert werden kann. 

Diese Klasse funktioniert ähnlich wie die List-Klasse (siehe Abschnitt 8.5.8), jedoch 

erscheint die Liste in einer eigenen Shell über der im Konstruktor spezifizierten Shell. 

Üblicherweise wird diese Klasse verwendet, um innerhalb einer Tabellenzelle Werte aus 

einer Liste auszuwählen. 

Diese Klasse ist als eine Unterklasse von Composite implementiert und organisiert seine 

Kindelemente horizontal oder vertikal (wie angegeben) und durch verschiebbare Rahmen 

(Sash) getrennt (siehe Abschnitt 8.5.10). Jedem Kindelement kann ein Gewicht zugeordnet 

werden, um Breite bzw. Höhe des Kindelements vorzugeben. Mit der Methode setMaximizedControl() 

kann ein einzelnes Kindelement temporär maximiert und die anderen 

minimiert werden. 

Diese Klasse implementiert ein ein- oder mehrzeiliges Texteingabefeld ähnlich der Klasse 

Text. Zusätzlich werden jedoch bestimmte Textattribute unterstützt (Vorder- und Hintergrundfarbe, 

Textfont, fetter, kursiver und normaler Textstil). Diese Funktionalität reicht für 

Programmeditoren aus, für die Textverarbeitung jedoch nicht. 

Die Textformatierung erfolgt mit Hilfe der Methoden getStyleRangeAtOffset(), get- 

StyleRanges(), setStyleRange(), setStyleRanges(), mit denen StyleRange-Instanzen abgefragt 

und gesetzt werden können. Außerdem gibt es die Methoden getLineBackground() 

und setLineBackground() zum Abfragen und Setzen der Hintergrundfarbe einer Zeile. 

Alternativ zu diesen Methoden kann eine eigene Stilverarbeitung mit Hilfe von Line- 

StyleListener- bzw. LineBackgroundListener-Instanzen implementiert werden. 

Der Textinhalt eines StyledText-Widgets muss das Interface StyledTextContent implementieren. 

Insofern können Sie auch eigene Inhaltsmodelle definieren. Mit der Method set- 

Content() kann ein StyledText-Widget initialisiert werden. 

Diese Klasse entspricht in ihrer Funktion der Klasse Tree (siehe Abschnitt 8.5.9). Allerdings 

weicht die grafische Darstellung ab: Die Baumstruktur erscheint als eine Serie von hierarchisch 

eingerückten Tabellen, die Linien, welche die Zweige des Baums andeuten sollen, 

entfallen. Die einzelnen Baumknoten werden durch TableTreeItem-Instanzen gebildet. 

Diese Klassen gleichen dem oben erwähnten ControlEditor, jedoch spezialisiert auf die 

Klassen Table, Tree und TableTree. Die Eclipse-API-Referenzdokumentation enthält 

Beispiele, in denen einzelnen TableItem-, TreeItem- und TableTreeItem-Instanzen ein 

Textfeld zugeordnet wird, das die Modifikation der jeweiligen Elemente erlaubt.

188 


// Äußere SashForm erzeugen 

SashForm sf1 = new SashForm(toplevelShell, SWT.HORIZONTAL); 

// Innere SashForm erzeugen 

SashForm sf2 = new SashForm(sf1, SWT.VERTICAL); 

// Inhalt für vertikale SashForm erzeugen 

List list1 = new List(sf2, SWT.NONE); 

list1.setItems(new String[]{"red", "green", "blue"}); 


list2.setItems(new String[]{"A", "B", "C"}); 

// Gleichmäßig gewichten 

sf2.setWeights(new int[] {100,100}); 

// Inhalt für horizontale SashForm erzeugen 


list3.setItems( 

new String[]{"one", "two", "three", "four", "five", "six"}); 

// Unterschiedlich gewichten 

sf1.setWeights(new int[] {100,200}); 

Abb. 8–9 Das Ergebnis: eine horizontale und eine vertikale Trennleiste, welche drei 

Listenfelder voneinander trennen. Beide Trennleisten können mit der Maus verschoben 

werden. Wird die Größe des Fensters geändert, verschieben sich die Trennleisten entsprechend. 

8.5.14 Das Browser-Widget 

Seit Eclipse V3 ist auch ein Webbrowser als Widget verfügbar und 

zwar als Klasse Browser in Package org.eclipse.swt.browser. Damit 

wird es möglich, auf einfache Art und Weise HTML-Inhalte in SWT- 

Applikationen anzuzeigen. Das Eclipse-Team hat freilich hier keinen 

eigenen Browser implementiert, sondern benutzt die nativen Browser 

der Ablaufplattform. Unter Windows implementiert die Klasse Browser 

eine OLE-Einbettung des Internet Explorers. Unter Linux wird Mozilla 

benutzt, unter Mac OS X der Safari-Browser. Angenehm an dieser 

Strategie ist, dass das Browser-Widget genauso mächtig ist wie die verwendeten 

Webbrowser. Sicherheits- und andere Einstellungen im 

Internet Explorer oder in Mozilla beeinflussen auch das Browser-Widget. 

Nachteilig an dieser Strategie ist, dass sich das Widget in vielerlei 

Hinsicht nicht wie ein Standard-Widget verhält. So kann man z.B. die-

8.6 Layouts 

sem Widget kein eigenes Kontextmenü zuordnen (der Browser hat ja 

schon eines), MouseListener und KeyListener empfangen keine Ereignisse, 

und auf der Oberfläche des Widgets kann man weder herummalen 

noch andere Widgets darauf anordnen. 

Dafür verfügt das Browser-Widget aber über spezielle Methoden, 

um z.B. eine Webseite an einer spezifizierten Adresse anzuzeigen 

(setURL()) oder die URL der aktuellen Seite abzufragen (getURL()). 

Mit der Methode setText() kann dem Browser direkt ein HTML-Text 

zur Anzeige übergeben werden. Daneben gibt es Methoden für die 

Navigation wie back(), isBackEnabled(), forward(), isForwardEnabled(), 

refresh() und stop(). 

Außerdem kann das Browser-Widget mit verschiedenen Listenern 

(CloseWindowListener, LocationListener, OpenWindowListener, ProgressListener, 

StatusTextListener, TitleListener, Visibility- 

WindowListener) instrumentiert werden, die auf Status- oder Inhaltsänderungen 

des eingebetteten Browsers reagieren können. 

In Abschnitt 10.5 zeigen wir das Browser-Widget in einer praktischen 

Anwendung. Weitere Beispiele finden Sie in [Daum2004]. 

8.6 Layouts 

Layouts werden benutzt, um GUI-Elemente auf einem Composite automatisch 

anzuordnen. Das Layout errechnet die Position und Größe 

jedes GUI-Elements, das auf dem Composite angebracht ist. Sollte das 

Composite in der Größe verändert werden – durch Programmaktion 

oder durch Benutzereinwirkung –, so wird die Anordnung der GUI- 

Elemente automatisch neu berechnet. 

Normalerweise werden dabei alle GUI-Elemente über einen Kamm 

geschoren. Allerdings ist es auch möglich, das Layout individueller 

GUI-Elemente durch die Zuordnung spezifischer Layoutdaten zu 

beeinflussen. Das erfolgt mit der Control-Methode setLayoutData(). 

Eclipse stellt fünf vordefinierte Layout-Klassen zur Verfügung. 

Außerdem besteht die Möglichkeit, selbst Layout-Klassen zu erstellen. 

Die Namen der vordefinierten Layout-Klassen folgen alle dem Muster 

»*Layout«. Die Namen der zugehörigen Klassen für die individuellen 

Layoutdaten folgen dem Muster »*Data«. Bis auf die Klasse StackLayout, 

die im Package org.eclipse.swt.custom (siehe Abschnitt 8.5.13) 

enthalten ist, sind alle anderen vordefinierten Layouts im Package 

org.eclipse.swt.layout enthalten. 

An dieser Stelle sei auch auf den ausgezeichneten Artikel Understanding 

Layouts in SWT von Carolyn MacLeod und Shantha Ramachandran 

[MacLeod2002] hingewiesen. 

189

190 


Hinweis: In manchen Fällen ist es einfacher und benutzerfreundlicher, an 

Stelle eines Composites mit einem Layout eine SashForm-Komponente (siehe 

Abschnitt 8.5.13) zu verwenden. Diese erlaubt dem Endbenutzer eine eigenständige 

Aufteilung des vorhandenen Raumes. 

8.6.1 Visuelle Übersicht 

Die beste Übersicht über die verschiedenen Layouts ist in den Beispielapplikationen 

zu Eclipse enthalten. Dazu rufen wir die Funktion Window>Show 

View>Other ... auf. Im folgenden Dialog wählen wir die 

Applikation SWT Examples>SWT Layouts aus. Diese Applikation 

erscheint dann auch prompt im Fenster rechts unten (Abb. 8–10). 

Damit wir etwas mehr Platz haben, maximieren wir diese Applikation 

mit einem Doppelklick auf den Reiter. 

Abb. 8–10 Verschiedene FillLayout-, RowLayout-, GridLayout- und FormLayout-Konfigurationen 

können mit der SWT Layouts-Beispielapplikation durchprobiert werden. Ein 

Druck auf den Code-Button zeigt den erzeugten Source-Code. 

So kann man diese Beispielapplikation zur Not als GUI-Designer verwenden. 

Da diese Applikation die verschiedenen Layouts am besten visualisieren 

kann, werden wir im Folgenden auf eine Abbildung der verschiedenen 

Layouts verzichten. 

8.6.2 Die Klasse FillLayout 

FillLayout ist das einfachste der vordefinierten Layouts. Es besagt 

schlicht, dass die GUI-Elemente das Composite komplett ausfüllen. Es 

gibt weder Zwischenräume zwischen den einzelnen GUI-Elementen 

noch Randbereiche, und auch ein automatischer Umbruch bei ungenügendem 

Platz ist nicht möglich. Alle GUI-Elemente haben die gleiche 

Größe, wobei die Höhe vom höchsten GUI-Element und die Breite

8.6 Layouts 

vom breitesten GUI-Element bestimmt wird. Typische Einsatzfälle für 

diese Layout-Klasse sind z.B. Werkzeugleisten, bei denen die einzelnen 

Tasten unmittelbar aneinander liegen, oder auch der Fall, wenn ein 

einzelnes GUI-Element ein Composite komplett ausfüllt. 

Normalerweise werden die GUI-Elemente in horizontaler Richtung 

aneinander positioniert, allerdings lässt sich durch die Zuweisung 

der Stilkonstante SWT.VERTICAL an das type-Feld des Layouts auch eine 

vertikale Ausrichtung erzwingen: 

FillLayout fillLayout = new FillLayout(); 

fillLayout.type = SWT.VERTICAL; 

composite.setLayout(fillLayout); 

new Button(composite, SWT.RADIO).setText("One"); 

new Button(composite, SWT.RADIO).setText("Two"); 

new Button(composite, SWT.RADIO).setText("Three"); 

Bei FillLayout besteht keine Möglichkeit, die Größe der einzelnen 

GUI-Elemente individuell zu setzen. 

8.6.3 Die Klasse RowLayout 

Ähnlich wie beim FillLayout ordnet das RowLayout die GUI-Elemente 

in einer Reihe an. Dabei gibt es jedoch zusätzliche Optionen: 

type wie bei FillLayout 

Ist dieses Feld auf den Wert true gesetzt (Standardeinstellung), so werden 

wrap 

überzählige GUI-Elemente in eine neue Reihe umgebrochen, wenn der Platz nicht 

ausreicht. 

pack 

justify 

marginLeft 

marginTop 

marginRight 

marginBottom 

spacing 

Das folgende Beispiel zeigt, wie die Felder einer RowLayout-Instanz 

gesetzt werden können: 

191 

Ist dieses Feld auf den Wert true gesetzt (Standardeinstellung), so werden alle 

GUI-Elemente in ihrer natürlichen Größe und so weit links wie möglich dargestellt. 

Andernfalls füllen die GUI-Elemente den kompletten verfügbaren Platz aus, ähnlich 

wie bei FillLayout. 

Ist dieses Feld auf den Wert true gesetzt, so werden alle GUI-Elemente gleichmäßig 

über den verfügbaren Raum verteilt. Die Standardeinstellung ist »false«. 

Diese Felder kontrollieren die Größe des Randbereichs in Pixeln. 

Dieses Feld kontrolliert den Minimalabstand zwischen 

GUI-Elementen in Pixeln.

192 

numColumns 

makeColumnsEqualWidth 


RowLayout rowLayout = new RowLayout(); 

rowLayout.wrap = false; 

rowLayout.pack = false; 

rowLayout.justify = true; 

rowLayout.type = SWT.VERTICAL; 

rowLayout.marginLeft = 10; 

rowLayout.marginTop = 5; 

rowLayout.marginRight = 10; 

rowLayout.marginBottom = 8; 

rowLayout.spacing = 5; 

composite.setLayout(rowLayout); 

RowData Höhe und Breite jedes einzelnen GUI-Elements innerhalb einer RowLayout-Instanz 

können individuell mittels RowData-Instanzen gesetzt werden. 

Im folgenden Beispiel erzeugen wir zwei Tasten und setzen deren 

Höhe und Breite. 

Button button1 = new Button(composite, SWT.PUSH); 

button1.setText("70x20"); 

button1.setLayoutData(new RowData(70, 20)); 

Button button2 = new Button(composite, SWT.PUSH); 

button2.setText("50x35"); 

button2.setLayoutData(new RowData(50, 35)); 

8.6.4 Die Klasse GridLayout 

Die Klasse GridLayout ist die wohl nützlichste und mächtigste Klasse 

der vordefinierten Layout-Klassen. Allerdings ist sie auf Grund der vielen 

verschiedenen Einstellungsmöglichkeiten auch recht kompliziert zu 

handhaben. Wer etwas Erfahrung mit der Gestaltung von HTML-Seiten 

mit Hilfe von Tabellen hat, weiß, wovon ich rede. 

Das GridLayout hat in der Tat einige Ähnlichkeiten mit HTML- 

Tabellen. Auch hier gibt es Reihen und Spalten, und es ist möglich, 

horizontal oder vertikal angrenzende Tabellenelemente miteinander zu 

verschmelzen. 

Die folgenden Optionen stehen für das GridLayout zur Verfügung: 

Anzahl der Spalten. Die Anzahl der Reihen ergibt sich aus der Anzahl der GUI- 

Elemente und der Anzahl der Spalten. 

Ist dieses Feld auf den Wert true gesetzt, so wird allen Spalten die gleiche Breite 

zugeordnet. Die Standardeinstellung ist »false«. 

marginHeight Dieses Feld kontrolliert die Größe des Randbereichs oben und unten in Pixeln. 

marginWidth Dieses Feld kontrolliert die Größe des Randbereichs links und rechts in Pixeln. 

horizontalSpacing Dieses Feld kontrolliert den Minimalabstand zwischen den Spalten in Pixeln. 

verticalSpacing Dieses Feld kontrolliert den Minimalabstand zwischen den Reihen in Pixeln.

8.6 Layouts 

Das folgende Beispiel zeigt, wie die einzelnen Optionen für eine Grid- 

Layout-Instanz gesetzt werden: 

GridLayout gridLayout = new GridLayout(); 

gridLayout.numColumns = 3; 

gridLayout.marginWidth = 10; 

gridLayout.makeColumnsEqualWidth = true; 

gridLayout.marginHeight = 5; 

gridLayout.horizontalSpacing = 6; 

gridLayout.verticalSpacing = 4; 

gridLayout.makeColumnsEqualWidth = true; 

composite.setLayout(gridLayout); 

Die Layout-Optionen, die mit Hilfe von GridData-Instanzen für individuelle 

GUI-Elemente innerhalb einer GridLayout-Instanz gesetzt werden 

können, sind recht üppig. So verfügen GridData-Instanzen über die 

folgenden Felder: 

grabExcessHorizontalSpace 

grabExcessVerticalSpace 

heightHint 

Bestimmte Attribute können bereits im GridData()-Konstruktor gesetzt 

werden. Dazu stehen folgende Stilkonstanten zur Verfügung: 

GridData 

Ist dieses Feld auf den Wert true gesetzt, so füllt das GUI-Element den eventuell 

verbleibenden horizontalen Raum aus. Die Standardeinstellung ist »false«. 

Ist dieses Feld auf den Wert true gesetzt, so füllt das GUI-Element den eventuell 

verbleibenden vertikalen Raum aus. Die Standardeinstellung ist »false«. 

193 

Spezifiziert eine minimale Höhe in Pixeln. Ist hier ein Wert angegeben, so ist bei dem 

jeweiligen GUI-Element eine etwaige vertikale Scroll-Funktion außer Kraft gesetzt! 

Spezifiziert, wie das GUI-Element horizontal in seiner Zelle ausgerichtet wird. Die 

folgenden Konstanten können angegeben werden: 

GridData.BEGINNING (Standard) 

horizontalAlignment 

GridData.CENTER 

GridData.END 

GridData.FILL 

horizontalIndent Spezifiziert in Pixeln, wie weit ein GUI-Element von links eingerückt wird. 

horizontalSpan 

verticalAlignment 

verticalSpan 

widthHint 

Spezifiziert, wie viele Zellen das GUI-Element in horizontaler Richtung verbraucht 

(die Zellen werden miteinander verschmolzen). 

Spezifiziert, wie das GUI-Element vertikal in seiner Zelle ausgerichtet wird. Die 

folgenden Konstanten können angegeben werden: 

GridData.BEGINNING 

GridData.CENTER (Standard) 

GridData.END 

GridData.FILL 

Spezifiziert, wie viele Zellen das GUI-Element in vertikaler Richtung verbraucht 

(die Zellen werden miteinander verschmolzen). 

Spezifiziert eine minimale Breite in Pixeln. Ist hier ein Wert angegeben, so ist die 

horizontale Scroll-Funktion außer Kraft gesetzt!

194 


Konstante Äquivalent 

GridData.GRAB_HORIZONTAL grabExcessHorizontalSpace = true 

GridData.GRAB_VERTICAL grabExcessVerticalSpace = true 

GridData.HORIZONTAL_ALIGN_BEGINNING 

horizontalAlignment = 

GridData.BEGINNING 

GridData.HORIZONTAL_ALIGN_CENTER horizontalAlignment = GridData.CENTER 

GridData.HORIZONTAL_ALIGN_END horizontalAlignment = GridData.END 

GridData.HORIZONTAL_ALIGN_FILL horizontalAlignment = GridData.FILL 

GridData.VERTICAL_ALIGN_BEGINNING verticalAlignment = GridData.BEGINNING 

GridData.VERTICAL_ALIGN_CENTER verticalAlignment = GridData.CENTER 

GridData.VERTICAL_ALIGN_END verticalAlignment = GridData.END 

GridData.VERTICAL_ALIGN_FILL verticalAlignment = GridData.FILL 

GridData.FILL_HORIZONTAL 

HORIZONTAL_ALIGN_FILL | 

GRAB_HORIZONTAL 

GridData.FILL_VERTICAL VERTICAL_ALIGN_FILL | GRAB_VERTICAL 

GridData.FILL_BOTH FILL_VERTICAL | FILL_HORIZONTAL 

In Abschnitt 10.3 finden Sie ein Beispiel für die Anwendung der Grid- 

Layout-Klasse. 

Sollten alle diese Layout-Möglichkeiten nicht ausreichen, kann 

man immer noch Composite-Instanzen mit Hilfe von GridLayouts 

schachteln, eine Technik, die von HTML-Seite her wohl bekannt ist. 

8.6.5 Die Klasse FormLayout 

Die Klasse FormLayout wurde mit Eclipse 2.0 eingeführt. Sie erlaubt es, 

die einzelnen GUI-Elemente auf einer zweidimensionalen Fläche 

jeweils aneinander bzw. an die Ränder des übergeordneten Composite 

zu docken. Das geschieht mit Hilfe von FormAttachment-Instanzen. 

Für FormLayout stehen nur die folgenden Optionen zur Verfügung: 



FormData Die eigentlichen Layout-Möglichkeiten stecken in den Klassen Form- 

Data und FormAttachment. FormData erlaubt folgende Optionen für 

jedes einzelne GUI-Element:

8.6 Layouts 

height Die gewünschte Höhe des GUI-Elements in Pixeln. 

width Die gewünschte Breite des GUI-Elements in Pixeln. 

top 

bottom 

left 

right 

Dabei gibt es für FormAttachment-Instanzen zwei Spielarten: 

! Angabe einer relativen Position im Composite 

! Angabe relativ zu einem anderen GUI-Element 

Für die erste Methode der Positionierung stehen zwei Konstruktor- 

Varianten zur Verfügung: 

und 

FormAttachment fa = new FormAttachment(prozent, offset); 

FormAttachment fa = new FormAttachment(zaehler, nenner, offset); 

Die Position p ermittelt sich dann aus der Höhe oder Breite d des Composite 

wie folgt: 

p = d*zaehler/nenner+offset 

Wurde nur ein Prozentwert angegeben, so ist die Formel natürlich: 

p = d*prozent/100+offset 

Nehmen wir z.B. an, dass unser Composite 400 Pixel breit ist und 300 

Pixel hoch ist. Erzeugen wir nun eine FormAttachment-Instanz mit 

FormAttachment(30,10) und weisen sie dem top-Feld einer FormData- 

Instanz zu, so ergibt sich: 

p = 30/100*300+5 = 95 

Der obere Rand unseres GUI-Elements ist also 95 Pixel vom oberen 

Rand der Client-Area des Composite entfernt. Würden wir dieselbe 

Instanz stattdessen dem bottom-Feld zuweisen, so wäre der untere 

Rand unseres GUI-Elements 95 Pixel vom unteren der Client-Area des 

Composite entfernt. 

Würden wir dagegen dieselbe Instanz dem left-Feld zuweisen, so 

ergäbe sich 

p = 30/100*400+5 = 125 

Eine FormAttachment-Instanz, die angibt, auf was sich die obere/ 

untere/linke/rechte Kante des GUI-Elements beziehen soll. 

Der linke Rand unseres GUI-Elements ist also 125 Pixel vom linken 

Rand der Client-Area des Composite entfernt. Entsprechendes gilt für 

die Zuweisung an das right-Feld. 

FormAttachment 

Composite-Position 

195

196 


Referenz-GUI-Element Für die zweite Methode der Positionierung gibt es drei Konstruktor-Varianten: 

Zwischen GUI-Elementen 

hin- und herschalten 

FormAttachment (control, offset, alignment) 

FormAttachment (control, offset) 

FormAttachment (control) 

Der Parameter control gibt dabei die Control-Instanz (also das GUI- 

Element) an, auf die wir uns beziehen. 

Der Parameter offset gibt den Abstand zwischen den GUI-Elementen 

an. Wird der Parameter weggelassen, ist der Abstand Null. 

Der Parameter alignment gibt an, auf welche Kante des Referenzelements 

wir uns beziehen. Für Zuweisungen an top- und bottom-Felder 

können hier die Stilkonstanten SWT.TOP, SWT.BOTTOM und SWT.CENTER 

verwendet werden. Für Zuweisungen an left- und right-Felder sind 

es die Konstanten SWT.LEFT, SWT.RIGHT und SWT.CENTER. Wird der Parameter 

alignment weggelassen, so wird die nächstliegende Kante 

benutzt. 

8.6.6 Die Klasse StackLayout 

Diese Klasse ist im Unterschied zu den vorigen vier vordefinierten Layouts 

nicht im Package org.eclipse.swt.layout enthalten, sondern im 

Package org.eclipse.swt.custom. Sie unterscheidet sich von anderen 

Layout-Klassen auch darin, dass innerhalb eines Composite immer nur 

ein GUI-Element sichtbar ist. Der Grund dafür ist, dass alle GUI-Elemente 

gleich groß gemacht werden und an der gleichen Stelle übereinander 

positioniert sind. Damit ist immer nur das oberste Element sichtbar. 

Die Klasse StackLayout ist dann sinnvoll, wenn man zwischen 

GUI-Elementen hin- und herschalten will. Man braucht lediglich die 

gewünschte Control-Instanz an die höchste Position zu bringen. 

Für StackLayout stehen die folgenden Optionen zur Verfügung: 



topControl Die sichtbare Control-Instanz. 

Im folgenden Beispiel legen wir zwei Button-Instanzen übereinander. 

Wird eine Taste gedrückt, wird jeweils die andere Taste sichtbar: 

// Neues Composite erzeugen 

final Composite stackComposite = new Composite(composite,SWT.NULL); 

final StackLayout stackLayout = new StackLayout(); 

// Text-Buttons erzeugen 

final Button buttonA = new Button(stackComposite, SWT.PUSH);

uttonA.setText("Taste A"); 

final Button buttonB = new Button(stackComposite, SWT.PUSH); 

buttonB.setText("Taste B"); 


buttonA.addSelectionListener(new SelectionAdapter() { 


stackLayout.topControl = buttonB; 

// Neues Layout erzwingen 

stackComposite.layout(); 

// Fokus auf sichtbare Taste setzen 

buttonB.setFocus(); 

} 

}); 

buttonB.addSelectionListener(new SelectionAdapter() { 


stackLayout.topControl = buttonA; 

// Neues Layout erzwingen 

stackComposite.layout(); 

// Fokus auf sichtbare Taste setzen 

buttonA.setFocus(); 

} 

}); 

// Layout initialisieren 

stackLayout.topControl = buttonA; 

stackLayout.marginWidth = 10; 

stackLayout.marginHeight = 5; 

// Layout setzen 

stackComposite.setLayout(stackLayout); 

8.7 Grafik 

8.7 Grafik 

Die Interfaces und Klassen für grafische Operationen sind im Package 

org.eclipse.swt.graphics enthalten. Im Wesentlichen orientiert sich 

der Funktionsumfang dieser Bibliothek an den grafischen Fähigkeiten 

der unterstützten Plattformen. Obwohl sie etwas mehr bietet als die 

grafischen AWT-Grundfunktionen, reicht der Funktionsumfang nicht 

an den des Java2D-API heran. In Abschnitt 8.8 werden wir diskutieren, 

wie man den Funktionsumfang erweitern kann. 

8.7.1 Der Grafikkontext 

Die Klasse GC enthält alle für Zeichenoperationen benötigten Methoden 

– Methoden wie drawLine(), drawOval(), drawPolygon(), setFont(), 

getFontMetrics(), u.v.a.m. 

197

198 


Gezeichnet werden kann auf Instanzen aller Klassen, die das Drawable-Interface 

implementieren. Insbesondere sind das die Klassen 

Image, Control und ihre Unterklassen wie Canvas und Display. Dabei 

wird Image besonders für Double-Buffering-Zwecke eingesetzt, Canvas 

dient normalerweise als Zeichenfläche für Grafikausgaben (z.B. Diagramme) 

oder auch als Zeichenfläche für den Endbenutzer, Display 

dient der bildschirmfüllenden Ausgabe von Grafiken. 

Die Auswahl des Zeichenmediums erfolgt im Konstruktor GC(). 

Erzeugt man einen Grafikkontext mit Hilfe des GC()-Konstruktors, 

muss man die GC-Instanz mit dispose() wieder entsorgen, wenn 

sie nicht mehr benötigt wird, denn eine GC-Instanz belegt Betriebssystemressourcen. 

Im Regelfall wird man jedoch nicht selbst einen Grafikkontext 

erzeugen, sondern einen Grafikkontext benutzen, der von 

einem PaintEvent übergeben wird. Denn die goldene Regel bei der 

Grafikverarbeitung lautet: 

Alle grafischen Operationen werden innerhalb eines PaintListener-Objekts 

ausgeführt, also innerhalb der paintControl()-Ereignisverarbeitung einer 

Control-Instanz. 

Wir zeigen das an einem Beispiel, in dem wir eine grüne Zierlinie um 

eine Composite-Instanz zeichnen: 

composite.addPaintListener(new PaintListener () { 

public void paintControl(PaintEvent event){ 

// Display aus Ereignis holen 

Display display = event.display; 

// Grüne Systemfarbe holen - braucht nicht entsorgt zu werden 

Color green = display.getSystemColor(SWT.COLOR_DARK_GREEN); 

// Das Ereignis liefert auch den Grafikkontext 

GC gc = event.gc; 

// Linienfarbe setzen 

gc.setForeground(green); 

// Größe des nutzbaren Bereichs im Composite 

Rectangle rect = ((Composite) event.widget).getClientArea(); 

// Nun ein Rechteck zeichnen 

gc.drawRectangle(rect.x + 2, rect.y + 2, 

rect.width - 4, rect.height - 4); 

} 

});

8.7.2 Farben 

8.7 Grafik 

In einem Grafikkontext setzt man Linien- und Textfarben – wie oben 

gezeigt – mit Hilfe der Methode setForeground(). Füllfarben werden 

mit setBackground() gesetzt. 

Dazu muss man sich allerdings erst einmal Farbobjekte besorgen. 

Das kann auf zwei verschiedene Arten erfolgen: 

! Man holt sich eine Systemfarbe von einer Device-Instanz. Da Display 

eine Unterklasse von Device ist, können wir eine Systemfarbe 

mit Hilfe der Methode getSystemColor() von der Display-Instanz 

eines Widgets holen. Die dazu notwendigen COLOR_...-Konstanten 

sind in der Klasse SWT definiert. 

Farbobjekte, die man sich auf diese oder andere Weise von anderen 

Instanzen holt, dürfen nicht mit dispose() freigegeben werden, 

denn sie werden eventuell noch anderenorts benötigt! 

! Man fertigt Farbobjekte selbst an, z.B. 

Color red = new Color(device, 255,0,0) 

oder 

Color blue = new Color(device, new RGB(0,255,0)); 

Der Parameter device muss dabei vom Typ Device sein. RGB ist eine 

geräteunabhängige Klasse zur Darstellung von RGB-Farbtupeln. 

Auf Ausgabegeräten mit 24 Bit Farbtiefe ist die Farbdarstellung 

exakt, bei Ausgabegeräten mit geringerer Farbtiefe wird die Farbe 

von Eclipse so gut wie möglich angenähert [Moody2001]. 

Solch selbst angefertigte Farbobjekte müssen mit dispose() wieder 

entsorgt werden, wenn sie nicht mehr gebraucht werden. 

8.7.3 Schriftarten 

Ähnlich wie mit Farben verhält es sich auch mit Fonts. Der aktuelle 

Font wird im Grafikkontext mit setFont() gesetzt. 

! Den aktuellen Systemfont kann man sich von einer Device-Instanz 

mit Hilfe der Methode getSystemFont() holen. Einen solchen Font 

darf man nicht mit dispose() entsorgen. 

! Neue Font-Instanzen können mit Hilfe eines Konstruktors erzeugt 

werden, z.B. 

Font font = new Font(device,"Arial",12,SWT.ITALIC) 

oder 

Font font = new Font(device,new FontData("Arial",12,SWT.ITALIC)) 

FontData ist eine geräteunabhängige Repräsentation einer Schriftart. 

Font-Instanzen müssen mit dispose() wieder entsorgt werden, 

wenn sie nicht mehr gebraucht werden. 

199

200 


Im folgenden Beispiel holen wir uns den aktuellen Systemfont, produzieren 

eine kursive Variante, konfigurieren den Grafikkontext mit diesem 

Font und zeichnen das Wort »Hello«: 

// Display-Instanz holen 

Display display = composite.getDisplay(); 

// Systemfont holen 

Font systemFont = display.getSystemFont(); 

// FontData-Objekte enthalten die Fonteigenschaften. 

// Bei manchen Betriebssystemen kann ein Font mehrere 

// FontData-Instanzen besitzen. Wir verwenden nur die Erste. 

FontData[] data = systemFont.getFontData(); 

FontData data0 = data[0]; 

// Den Fontstil auf kursiv setzen 

data0.setStyle(SWT.ITALIC); 

// Neuen Font erzeugen 

Font italicFont = new Font(display, data0); 

// Font im Grafikkontext setzen 

gc.setFont(italicFont); 

// Nicht vergessen: italicFont.dispose() im 

// DisposeListener von composite aufrufen. 

// Text an Position (4,4) mit transparentem Hintergrund zeichnen. 

gc.drawText("Hello",4,4,true); 

Die Klasse GC stellt noch einige weitere Methoden für die Textverarbeitung 

zur Verfügung. So liefert z.B. die Methode getFontMetrics() ein 

FontMetrics-Objekt, das die charakteristischen Maße des aktuellen 

Fonts enthält. Mit den Methoden stringExtent() und textExtent() 

kann man ermitteln, welche Abmessungen eine Zeichenkette hätte, 

wenn sie unter dem aktuellen Font gezeichnet würde. stringExtent() 

ignoriert dabei TAB- und CR-Zeichen. 

8.7.4 Bilder 

Die Klasse Image ist für die geräteabhängige Darstellung von Bildern 

verantwortlich. Image-Instanzen können auf verschiedene Arten 

erzeugt werden: durch Angabe eines java.io.Stream-Objekts, durch 

Angabe eines Dateinamens (absolut oder relativ zum Projekt) oder 

durch Angabe eines ImageData-Objekts. 

Die Klasse ImageData ist für die geräteunabhängige Darstellung 

von Bildern verantwortlich. Instanzen dieser Klasse können ebenfalls 

durch Angabe eines java.io.Stream-Objekts oder durch Angabe eines 

Dateinamen erzeugt werden. Sie können auch mit Hilfe der Methode 

getImageData() aus einer Image-Instanz geholt werden. So kann man 

jederzeit zwischen geräteabhängiger und geräteunabhängiger Darstellung 

wechseln.

8.7 Grafik 

Image und ImageData unterstützen Bilder sowohl im direkten RGB- 

Format als auch im Indexformat. Auch Transparenz wird unterstützt 

(alpha-Kanal bei RGB, Transparentfarbe im indizierten Format). Mindestens 

die folgenden Dateiformate werden gelesen: BMP, GIF, JPG, 

PNG, TIFF und ICO. In Abschnitt 8.5.5 hatten wir bereits gezeigt, wie 

ein Bild von einer Datei gelesen werden kann. 

Im folgenden Beispiel benutzen wir eine Image-Instanz für den 

doppelt gepufferten Bildaufbau. Double Buffering wird oft verwendet, 

um ein Flackern des Bildschirms zu vermeiden. Man legt zunächst eine 

genügend große Image-Instanz an, erzeugt dann eine GC-Instanz auf 

diese Image-Instanz und führt alle Zeichenoperationen innerhalb dieses 

GC-Kontextes aus. Anschließend zeichnet man das gesamte Image 

komplett auf das Ziel-Drawable. 

// Canvas erzeugen 

final Canvas canvas = new Canvas(composite,SWT.BORDER); 

// Weisse Systemfarbe holden 

Color white = canvas.getDisplay().getSystemColor(SWT.COLOR_WHITE); 

// Canvashintergrund setzen 

canvas.setBackground(white); 

// PaintListener zufügen 

canvas.addPaintListener(new PaintListener() { 

public void paintControl(PaintEvent e) { 

// Display aus Ereignis holen 

Display display = e.display; 

// Rote und schwarze Systemfarben holen 

// - brauchen nicht entsorgt zu werden 

Color black = display.getSystemColor(SWT.COLOR_BLACK); 

Color red = display.getSystemColor(SWT.COLOR_RED); 

// Das Ereignis liefert auch den Grafikkontext 

GC gc = e.gc; 

// Das Widget, das das Ereignis verursacht hat 

Composite source = (Composite) e.widget; 

// Größe der nutzbaren Fläche 

Rectangle rect = source.getClientArea(); 

// Puffer aufbauen 

Image buffer = new Image(display,rect.width,rect.height); 

// Neuer Grafikkontext für Puffer 

GC bufferGC = new GC(buffer); 

// verschiedene Zeichenoperationen 

bufferGC.setBackground(red); 

bufferGC.fillRectangle(5,5,rect.width-10,rect.height-10); 

bufferGC.setForeground(black); 

bufferGC.drawRectangle(5,5,rect.width-10,rect.height-10); 

bufferGC.setBackground(source.getBackground()); 

Double Buffering 

201

202 


} 

}); 

bufferGC.fillRectangle(10,10,rect.width-20,rect.height-20); 

// Nun das gepufferte Bild auf Canvas zeichnen 

gc.drawImage(buffer,0,0); 

// Den Grafikkontext des Puffers entsorgen 

bufferGC.dispose(); 

// Den Puffer entsorgen 

buffer.dispose(); 

Im System verwendete Bilder lassen sich von der aktuellen Display- 

Instanz mit der Methode getSystemImage() holen. Dabei stehen die folgenden 

Konstanten für die Identifizierung des Bildes zur Verfügung: 

SWT.ICON_ERROR, SWT.ICON_INFORMATION, SWT.ICON_QUESTION, SWT.ICON_ 

WARNING. 

8.7.5 Der Mauszeiger 

Ebenfalls im Package org.eclipse.swt.graphics befindet sich die 

Klasse Cursor, welche den Mauszeiger repräsentiert. Um der aktuellen 

Schreibmarke eine neue Gestalt zu geben, muss explizit eine neue 

Instanz dieser Klasse erzeugt werden. Dabei wird das aktuelle Display 

als Parameter übergeben, außerdem wird eine Stilkonstante angegeben, 

welche die Gestalt des Mauszeigers festlegt. Dabei hält natürlich 

die konkrete Ausprägung von der Ablaufplattform ab: 

CURSOR_ARROW Pfeil 

CURSOR_WAIT Warten 

CURSOR_CROSS Fadenkreuz 

CURSOR_APPSTARTING Start einer Anwendung 

CURSOR_HELP Hilfe 

CURSOR_SIZEALL Gesamtgröße ändern 

CURSOR_SIZENESW Größenänderung auf NO/SW-Achse 

CURSOR_SIZENS Größenänderung auf N/S-Achse 

CURSOR_SIZENWSE Größenänderung auf NW/SE-Achse 

CURSOR_SIZEWE Größenänderung auf W/O-Achse 

CURSOR_SIZEN Größenänderung Nordrichtung 

CURSOR_SIZES Größenänderung Südrichtung 

CURSOR_SIZEE Größenänderung Ostrichtung 

CURSOR_SIZEW Größenänderung Westrichtung 

CURSOR_SIZENE Größenänderung Nordostrichtung

CURSOR_SIZESE Größenänderung Südostrichtung 

CURSOR_SIZESW Größenänderung Südwestrichtung 

CURSOR_SIZENW Größenänderung Nordwestrichtung 

CURSOR_UPARROW Pfeil nach oben 

CURSOR_IBEAM Schreibmarke 

CURSOR_NO unzulässige Operation 

CURSOR_HAND Hand zum Verschieben 

8.8 Ein Widget mit Swing 

Seit Eclipse V3 besteht auch die Möglichkeit, die Pixel des Mauszeigers 

auch direkt über die Angabe einer ImageData-Instanz (siehe Abschnitt 

8.7.4) anzugeben. Eine zweite ImageData-Instanz kann eine zusätzliche 

Maske definieren. 

Wichtig ist, dass die Cursor-Instanz wieder mit dispose() freigegeben 

werden musss, wenn sie nicht mehr benötigt wird. Das Gleiche gilt 

für die ImageData-Instanzen. 


Auf Grund seiner Nähe zum jeweiligen Betriebssystem stellt das SWT 

einen neuen Ansatz für die Implementierung der untersten Schicht 

einer grafischen Benutzeroberfläche dar. Es stellt sich allerdings die 

Frage: Was ist mit den oberen Schichten? 

Wenn es um Dinge wie Fenster, Dialoge und Menüs geht, ist die 

Antwort einfach. Funktionalität, z.B. mit Swing bereitgestellt, steht in 

Eclipse als JFace-Bibliothek zur Verfügung (siehe Kapitel 9). 

Schwierig wird es allerdings, wenn es um andere Grafikschichten 

geht, z.B. eine leistungsfähige Grafikschicht, wie sie von Java2D oder 

Java3D bereitgestellt wird, SVG-Verarbeitung wie in Batik (www. 

apache.org) oder Bitmap-Manipulationen wie in Java Advanced Imaging 

(JAI). Alle diese APIs passten bisher nicht zum SWT. Fortgeschrittene 

Funktionen wie Kantenglättung, transparente Grafiken und Textrotation 

blieben deshalb außen vor. 

Mit Eclipse 3 hat sich das gründlich geändert. Nun ist es möglich, 

Swing- und AWT-Inhalte innerhalb von SWT-Composites zu präsentieren. 

Damit lassen sich auch grundsätzlich höhere Grafikschichten, 

die auf Swing oder dem AWT aufbauen, in SWT-Anwendungen integrieren. 

Und plötzlich macht dann Swing wieder Spaß, dank SWT. 

Unter Windows funktioniert das unter JRE 1.3 und 1.4, für die anderen 

Plattformen wird JRE 1.5 benötigt. 

203

204 


8.8.1 Eingebettete Inhalte 

Ermöglicht wird das durch die neue Stilkonstante EMBEDDED in der 

Klasse SWT. Ein Composite, das mit dieser Stilkonstante erzeugt wird, 

kann SWT-fremde Inhalte enthalten (allerdings keine zusätzlichen 

SWT-Inhalte). In Eclipse 3 können das zunächst java.awt.Frame-Komponenten 

sein, die mit Hilfe der Factory-Methode SWT_AWT.new_ 

Frame() erzeugt werden können. Also z.B. 

Composite awtContainer = new Composite(parent, SWT.EMBEDDED); 

java.awt.Frame myFrame = SWT_AWT.new_Frame(awtContainer); 

Nun kann man nach Herzenslust AWT- und Swing-Komponenten auf 

die übliche Art zu der so erzeugten Frame-Instanz hinzufügen. 

Außerdem verfügt die Klasse SWT_AWT noch über die Methode 

new_Shell(). Diese erzeugt für einen gegebenen AWT-Canvas eine 

SWT-Shell, so dass der AWT-Canvas zwar in einem eigenen Fenster, 

aber noch innerhalb der SWT-Applikation ausgeführt wird. 

8.8.2 Ereignisse 

Wie verhält es sich nun mit Ereignissen? Nun, das ist nicht besonders 

schwierig: den AWT- und Swing-Komponenten werden auf die übliche 

Art und Weise Listener zugeordnet, die auf die jeweiligen Ereignisse 

reagieren. Vorsicht ist allerdings geboten, wenn man aus einer solchen 

Ereignisverarbeitung auf SWT-Ressourcen zugreifen will. SWT und 

AWT laufen in verschiedenen Threads ab. Deshalb müssen diese 

Zugriffe, wie bereits in Abschnitt 8.5.2 diskutiert, in ein Runnable 

gekapselt und mit Hilfe der Display-Methode syncExec(), asyncExec() 

oder timerExec() ausgeführt werden. 

Und umgekehrt, beim Zugriff von der SWT-Ereignisverarbeitung 

auf AWT- bzw. Swing-Komponenten, funktioniert’s ganz ähnlich: auch 

hier wird die eigentliche Verarbeitung in ein Runnable gekapselt und 

dann mit Hilfe der AWT-Methode EventQueue.invokeLater() ausgeführt. 

Das wird vom AWT zwar nicht erzwungen (wie es das SWT 

macht), wird aber dringend empfohlen. 

Im folgenden Beispiel zeigen wir diese Techniken im Zusammenhang. 

Dieses Beispiel zeigt auch, wie man SWT-GUI-Elemente auf eine 

AWT-Oberfläche platzieren kann (in einer eigenen Shell). Das Beispiel 

implementiert einen Java2D-Canvas innerhalb einer SWT-Shell. Eine in 

SWT implementierte Taste erlaubt es, den Canvas zu löschen. Klickt 

man auf den Canvas, erscheint ein in SWT implementiertes Texteingabefeld 

auf dem Canvas. Mit einem weiteren Klick verschwindet dieses 

Feld wieder, und der eingegebene Text wird auf den Canvas geschrieben.

import java.util.ArrayList; 

import java.util.Iterator; 


import org.eclipse.swt.awt.SWT_AWT; 

import org.eclipse.swt.events.*; 

import org.eclipse.swt.graphics.*; 

import org.eclipse.swt.layout.*; 

import org.eclipse.swt.widgets.*; 

public class SWT2D { 

// Shell für Popup-Editor 

Shell eShell = null; 

// Text-Widget für Editor 

Text eText = null; 

// Liste eingegebener Zeichenketten 

ArrayList wordList = new ArrayList(12); 


SWT2D swtawt = new SWT2D(); 

swtawt.run(); 

} 


Zunächst wird die SWT-Shell erzeugt. Darin werden in einem GridLayout 

das Container-Composite (EMBEDDED) für den AWT-Canvas und 

später noch eine Taste platziert. 

private void run() { 

// Top-Level Shell erzeugen 


final Shell shell = new Shell(display); 

shell.setText("Java 2D-Beispiel"); 

// GridLayout für Canvas und Taste 

shell.setLayout(new GridLayout()); 

// Container für AWT-Canvas erzeugen 

final Composite canvasComp = new Composite(shell, SWT.EMBEDDED); 

// Vorzugsgröße setzen 

GridData data = new GridData(); 

data.widthHint = 600; 

data.heightHint = 500; 

canvasComp.setLayoutData(data); 

Dann wird mit Hilfe der Klasse SWT_AWT ein AWT-Frame im SWT- 

Composite erzeugt. Auf die übliche Art wird diesem Frame dann ein 

AWT-Canvas hinzugefügt. Vom Canvas holen wir uns den grafischen 

Kontext, auf dem wir später die Zeichenoperationen durchführen. 

Außerdem sichern wir uns die anfängliche affine Transformation dieses 

grafischen Kontexts, um später nach Rotationsoperationen den 

205

206 


Grafikkontext wieder auf den Grundzustand zurückbringen zu können. 

Außerdem schalten wir die Kantenglättung ein – eine weitere 

Schönheit von Java2D. 

// AWT-Frame für Canvas erzeugen 

java.awt.Frame canvasFrame = SWT_AWT 

.new_Frame(canvasComp); 

// Canvas erzeugen und zufügen 

final java.awt.Canvas canvas = new java.awt.Canvas(); 

canvasFrame.add(canvas); 

// Graphischen Kontext holen und in Java2D-Kontext umwandeln 

final java.awt.Graphics2D g2d = (java.awt.Graphics2D) canvas 

.getGraphics(); 

// Kantenglättung einschalten 

g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, 

RenderingHints.VALUE_ANTIALIAS_ON); 

// Ursprüngliche Transformation merken 

final java.awt.geom.AffineTransform origTransform = g2d 

.getTransform(); 

Nun erzeugen wir die Löschtaste. In ihrer Ereignisverarbeitung wird 

ein Neuzeichnen des Canvas veranlasst, und zwar durch den Aufruf 

der redraw()-Methode für das SWT-Container-Composite. 

// Clear-Taste anlegen und positionieren 

Button clearButton = new Button(shell, SWT.PUSH); 

clearButton.setText("Clear"); 

data = new GridData(); 

data.horizontalAlignment = GridData.CENTER; 

clearButton.setLayoutData(data); 

// Ereignisverarbeitung für Taste 

clearButton 

.addSelectionListener(new SelectionAdapter() { 


// Wortliste löschen und Canvas neu zeichnen 

wordList.clear(); 

canvasComp.redraw(); 

} 

}); 

Bei einem Mausklick auf den Canvas (hier befinden wir uns also in der 

AWT-Ereignisverarbeitung) wird das Texteingabefeld wechselweise 

sichtbar oder unsichtbar geschaltet. Nur bei der allerersten Benutzung 

wird dieser kleine Editor neu erzeugt. Da AWT-Canvassen natürlich 

keine SWT-Widgets zugefügt werden können, erzeugen wir diesen Editor 

in einer eigenen Shell. Wichtig ist, diese Shell nicht-modal anzule-


gen, so dass auch nach Öffnen der Shell der Canvas für Mausklicks 

zugänglich bleibt. 

Die Technik, diese Shell mit setVisible() abwechselnd sichtbar 

und unsichtbar zu schalten, ist einem wechselweisen Neuanlegen und 

Schließen vorzuziehen. Nicht nur werden damit Ressourcen geschont, 

auch werden damit unschöne Effekte vermieden. Nach einem close() 

würden Teile der close()-Ereignisverarbeitung erst nach Ablauf der 

AWT-Ereignisverarbeitung (also auch nach canvasComp.redraw()) ausgeführt, 

so dass an der Position des Editors ein hässlicher weißer Fleck 

zurückbleiben würde. Das ist bei Verwendung der Methode set- 

Visible(false) nicht der Fall. 

// Mausklicks auf dem Canvas verarbeiten 

canvas 

.addMouseListener(new java.awt.event.MouseListener() { 

public void mouseClicked( 

java.awt.event.MouseEvent e) {} 

public void mouseEntered( 


public void mouseExited( 


public void mousePressed( 

java.awt.event.MouseEvent e) { 

// Popup-Editor verwalten 

display.syncExec(new Runnable() { 

public void run() { 

if (eShell == null) { 

// Neue Shell anlegen: nicht-modal! 

eShell = new Shell(shell, SWT.NO_TRIM 

| SWT.MODELESS); 

eShell.setLayout(new FillLayout()); 

// Texteingabefeld 

eText = new Text(eShell, SWT.BORDER); 

eText.setText("Textrotation im SWT?"); 

eShell.pack(); 

// Positionieren (Displaykoordinaten) 

java.awt.Rectangle bounds = canvas 

.getBounds(); 

org.eclipse.swt.graphics.Point pos = canvasComp 

.toDisplay(bounds.width / 2, 

bounds.height / 2); 

Point size = eShell.getSize(); 

eShell.setBounds(pos.x, pos.y, size.x, 

207

208 


} 

} 

}); 

size.y); 

// Shell öffnen 

eShell.open(); 

} else if (!eShell.isVisible()) { 

// Editor versteckt, sichtbar machen 

eShell.setVisible(true); 

} else { 

// Editor sichtbar - Text holen 

String t = eText.getText(); 

// und Editor unsichtbar machen 

eShell.setVisible(false); 

// Text zur Liste zufügen und Canvas neu zeichnen. 

wordList.add(t); 

canvasComp.redraw(); 

} 

public void mouseReleased( 


}); 

Schließlich zeigen wir noch die Routine für das Zeichnen des Canvas- 

Inhaltes. Dies geschieht in einem PaintListener, der dem SWT-Container 

des Canvas zugeordnet ist. Wir setzen Java2D-Textrotation ein, 

um den eingegebenen Text sternförmig anzuordnen. Da es sich bei den 

verwendeten Ressourcen (Color, Font) um AWT-Ressourcen handelt, 

müssen diese auch nicht wie im SWT nach der Verwendung mit dispose() 

entsorgt werden. Die Java Garbage Collection wird sich schon 

darum kümmern. 

// Den Canvas neu zeichnen 

canvasComp.addPaintListener(new PaintListener() { 

public void paintControl(PaintEvent e) { 

// Die Verarbeitung der AWT-Event-Warteschlange übergeben 

java.awt.EventQueue.invokeLater(new Runnable() { 

public void run() { 

// Canvasmittelpunkt 

java.awt.Rectangle bounds = canvas.getBounds(); 

int originX = bounds.width / 2; 

int originY = bounds.height / 2; 

// Canvas rücksetzen 

g2d.setTransform(origTransform); 

g2d.setColor(java.awt.Color.WHITE); 

g2d.fillRect(0, 0, bounds.width, bounds.height);

} 

} 


// Font setzen 

g2d.setFont(new java.awt.Font("Myriad", 

java.awt.Font.PLAIN, 32)); 

double angle = 0d; 

// Sternförmige Anordnung vorbereiten 

double increment = Math.toRadians(30); 

Iterator iter = wordList.iterator(); 

while (iter.hasNext()) { 

// Textfarben im RGB-Farbkreis bestimmen 

float red = (float) (0.5 + 0.5 * Math 

.sin(angle)); 

float green = (float) (0.5 + 0.5 * Math 

.sin(angle + Math.toRadians(120))); 

float blue = (float) (0.5 + 0.5 * Math 

.sin(angle + Math.toRadians(240))); 

g2d.setColor(new java.awt.Color(red, green, 

blue)); 

// Text zeichnen 

String text = (String) iter.next(); 

g2d.drawString(text, originX + 50, originY); 

// Rotation für die nächste Textausgabe 

g2d.rotate(increment, originX, originY); 

angle += increment; 

} 

} 

}); 

} 

}); 

// Shell fertigstellen und öffnen 

shell.pack(); 

shell.open(); 

// SWT-Ereignisschleife 

while (!shell.isDisposed()) { 

if (!display.readAndDispatch()) display.sleep(); 

} 

display.dispose(); 

Abbildung 8–11 zeigt das Ergebnis. 

209

210 


Abb. 8–11 Textrotation und geglättete Kanten im SWT? Mit eingebettetem Java2D- 

Canvas kein Problem. 

8.9 Ausgabe auf Drucker 

Druckausgaben werden mit Hilfe der Klassen PrintDialog, Printer- 

Data und Printer bewerkstelligt. PrintDialog ist eine Unterklasse der 

uns schon bekannten abstrakten Klasse Dialog und repräsentiert den 

Druckauswahldialog des jeweiligen Betriebssystems. Als Ergebnis liefert 

PrintDialog entweder eine PrinterData-Instanz oder null zurück. 

Die PrinterData-Instanz enthält alle im Druckerauswahldialog gemachten 

Angaben wie Anzahl der Kopien, Druckbereich etc. Durch Abfrage 

der entsprechenden Felder (copyCount, scope etc.) kann man diese 

Angaben auswerten. 

Anschließend erzeugt man dann eine Instanz der Printer-Klasse, 

die eine Device-Unterklasse ist. Diese Instanz benutzt man, um einen 

neuen Grafikkontext zu erzeugen. Auf diesen Grafikkontext werden 

dann alle Ausgaben durchgeführt, die notwendig sind, um die Druckseiten 

zu füllen.

8.9 Ausgabe auf Drucker 

Zunächst wird die startJob()-Methode der Printer-Instanz aufgerufen, 

um einen neuen Druckauftrag zu erzeugen. Dann wird für 

jede Seite zunächst die startPage()-Methode aufgerufen, die grafischen 

Ausgaben auf den Grafikkontext durchgeführt und dann die 

endPage()-Methode aufgerufen. Sind alle Seiten ausgedruckt, wird der 

Druckauftrag mit endJob() geschlossen. Zum Schluss müssen noch der 

Grafikkontext und das Printer-Objekt mit dispose() entsorgt werden. 

Der folgende Beispielcode zeigt, wie es geht: 

// Taste für Druckausgabe erzeugen 

final Button primtButton = new Button(composite, SWT.PUSH); 

primtButton.setText("Drucken"); 


primtButton.addSelectionListener(new SelectionAdapter() { 


// Shell holen 

Shell shell = composite.getShell(); 

// Druckdialog erzeugen 

PrintDialog printDialog = new PrintDialog(shell); 

// und ausführen 

PrinterData printerData = printDialog.open(); 

// Prüfen, ob OK gedrückt 

if (printerData != null) { 

// Neue Printer-Instanz erzeugen 

Printer printer = new Printer(printerData); 

// Grafikkontext für diesen Drucker erzeugen 

GC gc = new GC(printer); 

// Druckauftrag öffnen 

if (!printer.startJob("Hello")) 

System.out.println("Printer start job failed"); 

else { 

// Erste Seite drucken 

if (!printer.startPage()) 

System.out.println("Printer start page 1 failed"); 

else { 

// grüne Systemfarbe vom Drucker holen und setzen 

Color green = 

printer.getSystemColor(SWT.COLOR_DARK_GREEN); 

gc.setForeground(green); 


gc.drawText("Hello World", 4, 4, true); 

// Seite beenden 

printer.endPage(); 

} 

211

212 


} 

}); 

} 

// Zweite Seite drucken 

if (!printer.startPage()) 

System.out.println("Printer start page 2 failed"); 

else { 

// blaue Systemfarbe vom Drucker holen und setzen 

Color blue = printer.getSystemColor(SWT.COLOR_BLUE); 

gc.setForeground(blue); 


gc.drawText("Hello Eclipse", 4, 4, true); 

// Seite beenden 

printer.endPage(); 

} 

// Druckauftrag beenden 

printer.endJob(); 

} 

// aufräumen 

gc.dispose(); 

printer.dispose(); 

Diese Routine zeigt allerdings nur den einfachsten Fall. Die Logik wird 

komplizierter, wenn man PrinterData-Angaben wie die Anzahl der 

Kopien, kollationierten Ausdruck oder Seitenbereiche berücksichtigen 

will. Auch ist es angeraten, sich vom Printer-Objekt mit Hilfe der 

Methode getDPI() die Druckauflösung zu holen und die grafischen 

Operationen entsprechend zu transformieren. 

8.10 Datentransfer 

Der SWT-Datentransfer umfasst sowohl den Austausch von Daten 

über die Zwischenablage als auch die Drag&Drop-Operationen mit 

der Maus. Die Klassen des Datentransfers befinden sich in Package 

org.eclipse.swt.dnd. 

8.10.1 Die Zwischenablage 

Als Zwischenablage wird die systemweite Zwischenablage der Ablaufplattform 

verwendet, zu der SWT einen Zugang bereitstellt. Implementiert 

wird dieser Zugang in Form der Klasse Clipboard. Diese Klasse 

stellt die Methoden setContents() und getContents() zur Verfügung, 

mit denen der Inhalt der Zwischenablage gesetzt bzw. abgefragt werden 

kann. Beim Erzeugen einer Clipboard-Instanz muss eine Display-

8.10 Datentransfer 

Instanz mit angegeben werden. Da das Clipboard Betriebssystemressourcen 

belegt, muss es mit dispose() wieder freigegeben werden, 

wenn es nicht mehr benötigt wird. 

Üblicherweise enthält eine Zwischenablage die kopierten Daten in 

mehreren Formaten. Textprozessoren legen beispielsweise die kopierten 

Textsegmente im RTF-Format und als einfachen Text ab. Eclipse 

unterscheidet diese Datenformate anhand von Transfertypen. Transfertypen 

sind als Unterklassen der abstrakten Klasse Transfer implementiert. 

Unter anderem sind vorhanden: FileTransfer, MarkerTransfer, 

RTFTransfer, TextTransfer und weitere speziellere Transfertypen. 

Hat man selbst speziellere Anforderungen an den Transfertyp, so kann 

man eigene Transfertypen (üblicherweise als Unterklasse von ByteArrayTransfer) 

implementieren. Der Quellcode von ByteArrayTransfer 

enthält eine Anleitung, wie das geht. 

Die jeweiligen konkreten Transfertypen dienen dabei der 

Umwandlung der typspezifischen Datenformate in ein betriebssystemabhängiges 

Datenformat für die Zwischenablage. Will man etwas in 

die Zwischenablage ablegen, so übergibt man der Methode setContents() 

ein Array mit den Daten in den verschiedenen Formaten sowie 

ein Array mit den Instanzen der Transfertypen. Entsprechend erhält 

man von der Methode getContents() unter Angabe eines Transfertyps 

die Daten aus der Zwischenablage im gewünschten Format. Mit der 

Methode getAvailableTypes() erhält man ein Array mit den in der 

Zwischenablage vertretenen Transfertypen. So erhält man schnell Aufschluss 

darüber, ob das gewünschte Format vorhanden ist, ohne den 

Inhalt der Zwischenablage lesen zu müssen. 

Im Plugin org.eclipse.swt.examples findet man unter Clipboard.java 

ein Beispielprogramm für die Verwendung der Zwischenablage. 

8.10.2 Drag&Drop 

Für Drag&Drop-Operationen benötigt man eine Datenquelle und eine 

Datensenke. Dabei kann die eine oder die andere von einer anderen 

Anwendung oder auch vom System bereitgestellt werden. In Eclipse 

wird die Datenquelle durch die Klasse DragSource implementiert, die 

Datensenke durch die Klasse DropTarget. Beide Klassen sind Unterklassen 

der Klasse Widget. Eine Anwendung kann mit mehreren Instanzen 

dieser Klassen ausgerüstet werden, allerdings muss jede Instanz 

eindeutig einer Control-Instanz zugeordnet werden. Das geschieht 

durch die Angabe der Control-Instanz im Konstruktor von DragSource 

oder DropTarget. Damit sind auch die Position und Größe des Daten- 

Transfertypen 

213

214 


transferelements festgelegt. Außerdem werden an dieser Stelle auch die 

erlaubten Operationen (DND.NONE, DND.MOVE, DND.COPY, DND.LINK) 

deklariert. 

Bei einer Drag&Drop-Operation erzeugen die Instanzen dieser 

Klassen entsprechende Ereignisse (DragSourceEvent bzw. DropTarget- 

Event), die mit entsprechenden Listener-Instanzen (DragSourceListener 

bzw. DropTargetListener) empfangen werden können. Die verschiedenen 

Methoden dieser Listener erlauben eine lückenlose Überwachung 

der Drag&Drop-Operation. So wird die dragStart()- 

Methode des DragSourceListeners beim Beginn der Drag&Drop-Operation 

aufgerufen. Wird der Bereich des DropTargets betreten, wird die 

dragEnter()-Methode des DropTargetListeners aufgerufen. drag- 

Leave() wird beim Verlassen dieses Bereichs aufgerufen und drag- 

Over(), wenn der Mauszeiger über diesem Bereich bewegt wird. Wird 

während der Operation der Operationsmodus geändert (z.B. durch 

Drücken von Strg oder Alt), wird die Methode dragOperationChanged() 

aufgerufen. Wird die Maustaste über der Datensenke losgelassen, 

so wird zunächst die Methode dropAccept() des DropTargetListeners 

aufgerufen. Hier besteht die letzte Möglichkeit, die Operation 

abzulehnen. Anschließend wird die Methode dragSetData() des 

DragSourceListeners aufgerufen, die nun die zu übermittelnden Daten 

bereitstellen muss. Dann erfolgt der Aufruf der Methode drop() beim 

DropTargetListener, die diese Daten entgegennimmt. Schließlich wird 

noch die Methode dragFinished() beim DragSourceListener aufgerufen. 

Hier besteht noch die Möglichkeit, notwendige Aufräumarbeiten 

durchzuführen. 

Bei allen Methoden, die vor der eigentlichen Datenübermittlung 

aufgerufen werden, kann noch Einfluss auf die Operation genommen 

werden. Durch Zuweisen von DND.DROP_NONE an das Feld detail des 

DropTargetEvents kann die Operation abgelehnt werden, durch das 

Zuweisen eines anderen Operationscodes kann die Operation modifiziert 

werden. 

Die eigentliche Datenübergabe erfolgt über das data-Feld des Drag- 

SourceEvents bzw. des DropTargetEvents. Wie bei der Zwischenablage 

(siehe Abschnitt 8.9.1) können die Daten in verschiedenen Formaten 

übergeben werden, die – genau wie dort – mit Hilfe von Transfertypen 

beschrieben werden. Die Felder dataType bzw. currentDataType der 

Ereignisobjekte enthalten den aktuellen Transfertyp. 

In Abschnitt 10.6 zeigen wir die Implementierung einer 

Drag&Drop-Datensenke am praktischen Beispiel. Einen ausführlichen 

Artikel über SWT-basiertes Drag&Drop findet man in der Eclipse Corner 

(www.eclipse.org) [Irvine2003].

8.11 Ressourcenverwaltung 

8.11 Ressourcenverwaltung 

Im Verlaufe dieses Kapitels haben wir verschiedene Ressourcen kennen 

gelernt, die, wenn nicht mehr benötigt, mit dispose() wieder freigegeben 

werden müssen. Dazu gehören insbesondere Instanzen der Klassen 

Color, Font, Image, GC, Cursor, Printer, Display, Shell und Clipboard. 

Bei allen diesen Ressourcen gilt der Grundsatz: 

Haben Sie etwas selbst erzeugt, müssen Sie es auch selbst entsorgen. 

Haben Sie dagegen eine Ressource von anderswo bezogen (z.B. mit get- 

SystemColor()), so dürfen Sie diese Ressource nicht selbst entsorgen. 

Also kurz gesagt, es gilt das Verursacherprinzip. Am Ende eines Programms 

braucht man freilich die Ressourcen nicht selbst zu entsorgen, 

das Betriebssystem sorgt dann schon automatisch dafür. Es geht hier 

also lediglich um Ressourcen, die nur in einem bestimmten Abschnitt 

und zu einer bestimmten Zeit von einer Applikation belegt werden. 

Das klingt zunächst recht einfach, erweist sich in der Praxis aber 

mitunter als kompliziert. Oft ist es so, dass eine Farbe, eine Schriftart 

oder ein Bild an mehreren Stellen eines Programms eingesetzt wird. 

Wer ist dann für die Entsorgung zuständig? Und ist es wirklich notwendig, 

eine Ressource zu entsorgen, die kurz hinterher wieder an 

anderer Stelle verwendet wird und dann neu erzeugt werden muss? 

Aus diesen Gründen greift man – fast wie im richtigen Leben – auf 

die Idee des Leihhauses zurück. Man implementiert einen Resource- 

Store, eine Instanz, die über das Leben mehrerer Ressourcen wacht, 

und erst dann, wenn der ResourceStore selbst entsorgt wird, werden 

auch seine Ressourcen entsorgt. Damit wird es auch möglich, die gleiche 

Ressource mehrfach zu verwenden. Das ist insbesondere bei Bildern 

nützlich, die oft recht speicherhungrig sind. 

Wir zeigen hier kurz das Prinzip eines ResourceStore an einem Beispiel 

für das Verwalten von Farbressourcen. Erhält die Klasse Color- 

Store eine Anfrage nach einer Farbe, die sie noch nicht kennt, so wird 

eine Color-Instanz neu erzeugt und dem ColorStore zugefügt. Ist die 

Farbe bereits bekannt, so wird die Anfrage aus dem ColorStore befriedigt. 

Erst wenn für den ColorStore die dispose()-Methode aufgerufen 

wird, werden alle Farbressourcen freigegeben. 

import java.util.HashMap; 

import java.util.Iterator; 

import java.util.Map; 

import org.eclipse.swt.graphics.Color; 

import org.eclipse.swt.graphics.Device; 

ResourceStore 

215

216 


public class ColorStore { 

} 

private static Map store = new HashMap(); 

/** 

* Method getColor. 

* @param name some Color name 

* @param device Device instance 

* @param r red-value 

* @param g green-value 

* @param b blue-value 

* @return Color requested color 

*/ 

public static Color getColor(String name,Device device, 

int r, int g, int b) { 

Object obj = store.get(name); 

if (obj == null) { 

Color newColor = new Color(device,r,g,b); 

store.put(name,newColor); 

return newColor; 

} 

return (Color) obj; 

} 

/** 

* Method dispose. 

*/ 

public static void dispose() { 

Iterator iter = store.values().iterator(); 

while (iter.hasNext()) { 

Color color = (Color) iter.next(); 

color.dispose(); 

} 

} 

Der Aufruf sieht dann z.B. so aus: 

Color green = ColorStore.getColor("green",display,0,255,0); 

Da alle Methoden der Klasse ColorStore statisch sind, kann Color- 

Store die Farben der gesamten Applikation verwalten. Erst wenn man 

keine Farben mehr braucht, entsorgt man alle Farben mit: 

ColorStore.dispose(); 

In Abschnitt 9.1 werden wir einige vorgefertigte Registraturen für 

Schriftarten und Bilder diskutieren.

8.12 Windows32-Unterstützung (OLE) 

8.12 Windows32-Unterstützung (OLE) 

SWT stellt eine spezielle Bibliothek für die Unterstützung des OLE- 

Mechanismus in Microsoft Windows Betriebssystemen zur Verfügung. 

Der Microsoft Win32 Object Linking and Embedding-Mechanismus 

(OLE) wird über die Klassen der Package org.eclipse.swt.ole.win32 

unterstützt. OLE gestattet es, OLE-Dokumente oder ActiveX-Kontrollelemente 

in andere Applikationen (Container) einzubetten. So wird es 

z.B. möglich, den Microsoft Internet Explorer als SWT-GUI-Element 

zu verwenden (das Browser-Widget ist so implementiert), oder aber ein 

Microsoft-Office-Dokument in ein SWT-GUI einzubetten. Um diese 

Klassen nutzen zu können, sollte man über ausreichende OLE-Kenntnisse 

verfügen. Ein kleines Beispiel-Plugin findet man in der Eclipse-Beispielsammlung 

unter org.eclipse.swt.examples.ole.win32_3.0.0. 

8.13 SWT auf dem Pocket PC 

Die Microsoft Pocket-PC-Plattform ist eine gültige Ablaufplattform 

für SWT-Anwendungen. Allerdings gelten dabei eine Reihe von Randbedingungen, 

die es bei der Erstellung von SWT-Applikationen für 

unter WindowsCE betriebenen Maschinen zu beachten gibt: 

! Noch mehr als Desktop-Anwender legen PDA-Anwender größten 

Wert auf Benutzungskomfort. 

! Die Prozessoren sind langsamer als bei Desktop-Maschinen. 

! Der verfügbare Speicherplatz ist meist kleiner als bei Desktop- 

Maschinen. 

! Die Größe des Anzeigeschirms ist im Vergleich zum Desktop stark 

eingeschränkt. 

! Oft steht keine Tastatur, sondern nur ein Stift zur Verfügung. 

Ist keine physische Tastatur vorhanden, ist es gängige Praxis, für Texteingaben 

eine emulierte Tastatur auf der Anzeigeeinheit abzubilden. 

Das verringert den für andere Fenster verfügbaren Platz. Pocket-PC- 

Anwendungen sollten deshalb beim Erzeugen einer Shell die Stilvariable 

SWT.RESIZE verwenden, um eine automatische Größenanpassung 

zu ermöglichen. 

Um die Größe der SWT-Bibliothek zu verkleinern, wurden bei der 

Pocket-PC-Version, die auf www.eclipse.org erhältlich ist, einige 

Packages weggelassen. Dazu gehören: 

! org.eclipse.swt.dnd (Drag&Drop, siehe Abschnitt 8.10.2) 

! org.eclipse.swt.ole (OLE, siehe Abschnitt 8.12) 

! org.eclipse.swt.accessibility (Eingabehilfen, siehe Abschnitt 8.14) 

217

218 


! org.eclipse.swt.custom (Spezielle Widgets, siehe Abschnitt 8.5.13) 

! org.eclipse.swt.printing (Druckfunktion, siehe Abschnitt 8.9) 

! org.eclipse.swt.program (Dateiassoziationen) 

Natürlich kann man auch eine SWT-Bibliothek nach eigenen Bedürfnissen 

zusammenstellen. Durch Löschen unbenutzter Klassen kann die 

Bibliothek weiter verkleinert werden. Der Pocket-PC-Artikel [Cornu2003] 

erklärt detailliert, wie man das macht, und wie man auch die Startzeit 

einer Pocket-PC-Applikation minimieren kann. 

8.14 Behindertengerechte Software 

Zum Schluss gehen wir noch kurz darauf ein, wie das SWT die Gestaltung 

behindertengerechter Software unterstützt. Insbesondere bei 

kommerziellen Entwicklungen ist die behindertengerechte Gestaltung 

der Benutzeroberfläche ein wichtiger Punkt. So dürfen beispielsweise 

viele Behörden nur Softwareprodukte erwerben, die behindertengerecht 

gestaltet wurden. 

In der Eclipse-Dokumentation gibt es ein besonderes Kapitel, wie 

SWT-basierte Oberflächen behindertengerecht gestaltet werden können. 

Wir finden diesen Abschnitt unter Platform Plugin Developer 

Guide unter Reference>Other Reference Information>Tips For 

Making User Interfaces Accessible. 

Manche Betriebssysteme unterstützen spezielle behindertengerechte 

Endgeräte und stellen dafür eine Programmierschnittstelle zur 

Verfügung. Eclipse unterstützt das Microsoft Active Accessibility 

(MSAA) API. Diese Unterstützung wird durch die Klassen im Package 

org.eclipse.swt.accessibility bereitgestellt. SWT-Control-Instanzen 

können durch den Aufruf getAccessible() eine Instanz der Klasse 

Accessible bereitstellen, die als Bindeglied zum Accessibility API 

dient.

8 Das SWT

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?