Byte-Welt Wiki - Benutzerbeiträge [de]

Malen in AWT und Swing

2013-01-12T06:34:19Z

AndreUhres: /* Malen in AWT und Swing */

__TOC__
=Malen in AWT und Swing=
Guter Malcode ist der Schlüssel zu einer leistungsfähigen Anwendung.

Von Amy Fowler.

[http://www.oracle.com/technetwork/java/painting-140037.html Copyright 1994-2008 Sun Microsystems, Inc.]

Übersetzung: André Uhres (Ich habe bei Sun die Erlaubnis angefragt, diesen Artikel zu übersetzen und hier zu veröffentlichen)

*HINWEIS vom Übersetzer: Zum Einstieg in das Malen mit Swing ist auch der folgende kurze und praxisorientierte Artikel gut geeignet: [[Malen in Swing Teil 1: der grundlegende Mechanismus]]

In einem graphischen System ist normalerweise ein Fensterdarstellungstoolkit dafür verantwortlich, einen Rahmen zur Verfügung zu stellen, der es relativ einfach macht, auf einer graphischen Benutzerschnittstelle (GUI) die richtigen Bits zur richtigen Zeit darzustellen.
Sowohl [[AWT]] (abstraktes Fensterdarstellungstoolkit) als auch [[Swing]] liefern solch einen Rahmen.
Aber die [[API]]s, die ihn verwirklichen, werden von manchen [[Entwickler]]n nicht gut verstanden -- ein Problem, das zu Programmen geführt hat, die nicht so leistungsfähig sind, wie sie sein könnten.

Dieser Artikel beschreibt die AWT und Swing Malmechanismen im Einzelnen. Sein Zweck ist, Entwicklern zu helfen, korrekten und leistungsfähigen GUI Malcode zu schreiben. Während der Artikel die allgemeinen Malmechanismen umfaßt (wo und wann man darstellt), erklärt er nicht, wie man die Swing Graphiken APIs benutzt, um korrekte Graphiken darzustellen. Um zu erlernen wie man nette Graphiken macht, besichtigen Sie bitte die [http://docs.oracle.com/javase/tutorial/2d/index.html Java 2D Website].

=Entwicklung des Swing Malsystems=

Als die ursprüngliche AWT API für [[JDK]] 1.0 entwickelt wurde, gab es nur heavyweight Komponenten ("heavyweight" bedeutet, daß die Komponente ihr eigenes undurchlässiges natives Fenster hat). Dies erlaubte es dem AWT, sich voll auf das Maluntersystem der nativen Plattform zu stützen. Dieser Entwurf kümmerte sich um Einzelheiten wie Beschädigungserkennung, Clipberechnung und Z-Einrichtung.

Mit der Einführung der lightweight Komponenten in JDK 1.1 (eine "lightweight" Komponente ist eine, die das native Fenster ihres nächsten heavyweight Vorfahrs wiederverwendet), mußte das AWT das Malen für lightweight Komponenten im gemeinsamen Java Code einführen. Somit gibt es feine Unterschiede bezüglich des Malvorgangs für heavyweight und lightweight Komponenten. Nach dem JDK 1.1, als das Swing Toolkit freigegeben wurde, stellte dieses seine eigenen Malmechanismen vor. In den meisten Fällen ähnelt und beruht der Swing Malmechanismus auf dem AWT. Aber er führt auch einige Unterschiede bezüglich der Mechanismen ein, sowie neue APIs, mit denen die Anwendungen den Malvorgang einfacher anpassen können.

=Malen in AWT=

Zu verstehen, wie die Mal-API von AWT arbeitet, hilft zu erkennen, was einen Malvorgang in einer Fensterdarstellungsumgebung auslöst. In AWT gibt es zwei Arten von Malvorgängen: systemausgelöstes Malen und anwendungsausgelöstes Malen.

==Systemausgelöstes Malen==

In einem systemausgelösten Malvorgang, bittet das System eine Komponente, ihren Inhalt darzustellen, normalerweise aus einem der folgenden Gründe:

* Die Komponente wird zum erstenmal sichtbar auf dem [[Bildschirm]] abgebildet.
* Die Komponente wird in der Größe verändert.
* Die Komponente wurde beschädigt und muß repariert werden (zum Beispiel wurde etwas verschoben, das vorher die Komponente verdeckte, und ein vorher verdeckter Teil der Komponente wird sichtbar).

==Anwendungsausgelöstes Malen==

Bei einem anwendungsausgelösten Malvorgang entscheidet die Komponente, daß sie ihren Inhalt aktualisieren muß, weil sich ihr interner [[Zustand]] geändert hat. Beispiel: ein Button erkennt, daß eine [[Maus]]taste betätigt worden ist und stellt fest, daß er einen "niedergedrückten" Button malen muß.

==Die paint Methode==

Ungeachtet dessen, wie ein Malantrag ausgelöst wird, benutzt das AWT einen "callback" ("Wiederholungsbesuch") Mechanismus zum Zeichnen, und dieser Mechanismus ist derselbe für heavyweight und lightweight Komponenten. Das heißt, daß ein [[Programm]] den Darstellungscode der [[Komponente]] innerhalb einer bestimmten überschriebenen [[Methode]] setzen sollte, und das [[Toolkit]] ruft diese Methode auf, wenn es Zeit ist zu malen. Die zu überschreibende Methode ist in '''java.awt.Component''':

<code=java>public void paint(Graphics g)</code=java>

Wenn AWT diese Methode aufruft, ist der Parameter "Graphics g" mit dem passenden Zustand für das Zeichnen auf dieser bestimmten Komponente vorkonfiguriert:

* Die Farbe des Graphics Objektes wird auf die foreground-Eigenschaft der Komponente eingestellt.
* Die Schriftart des Graphics Objektes wird auf die font-Eigenschaft der Komponente eingestellt.
* Die "translation" des Graphics Objektes wird so eingestellt, daß die Koordinate (0,0) die obere linke Ecke der Komponente darstellt.
* Das "clip"-Rechteck des Graphics Objektes wird auf den Bereich der Komponente eingestellt, der neu gezeichnet werden muss.

Programme müssen dieses Graphics Object verwenden (oder ein von ihm abgeleitetes) um die Oberfläche darzustellen. Sie sind frei, den Zustand des Graphics Objektes so zu ändern, wie es benötigt wird.
Hier ist ein einfaches Beispiel von einem paint callback, der einen gefüllten Kreis innerhalb einer Komponente darstellt:

<code=java> public void paint(Graphics g) {
// Dynamically calculate size information
Dimension size = getSize();
// diameter
int d = Math.min(size.width, size.height);
int x = (size.width - d)/2;
int y = (size.height - d)/2;

// draw circle (color already set to foreground)
g.fillOval(x, y, d, d);
g.setColor(Color.black);
g.drawOval(x, y, d, d);
}</code=java>

Entwickler, die neu bei AWT sind, werden einen Blick auf das PaintDemo Beispiel werfen wollen, das ein lauffähiges Programmbeispiel liefert, wie man den paint callback in einem AWT Programm verwendet:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/PaintDemo.java PaintDemo]

Im allgemeinen sollten Programme es vermeiden, darstellenden Code an irgendeinen Punkt zu setzen, wo er von außerhalb des Bereichs der paint callback Methode aufgerufen werden könnte. Warum? Weil solcher Code manchmal aufgerufen werden kann, wenn es nicht angebracht ist zu malen -- zum Beispiel bevor die Komponente sichtbar ist oder Zugang zu einem gültigen Graphics Objekt hat. Es wird nicht empfohlen, daß Programme paint() direkt aufrufen.

Um anwendungsausgelöstes Malen zu ermöglichen, liefert das AWT die folgenden '''java.awt.Component''' Methoden, damit Programme einen asynchronen Malvorgang anfragen können:

<code=java> public void repaint()
public void repaint(long tm)
public void repaint(int x, int y, int width, int height)
public void repaint(long tm, int x, int y, int width, int height)</code=java>

Der folgende Code zeigt ein einfaches Beispiel von einem MouseListener, der repaint() benutzt, um Updates auf einer theoretischen Taste auszulösen, wenn die Maus gedrückt und losgelassen wird:

<code=java> MouseListener l = new MouseAdapter() {
public void mousePressed(MouseEvent e) {
MyButton b = (MyButton)e.getSource();
b.setSelected(true);
b.repaint();
}

public void mouseReleased(MouseEvent e) {
MyButton b = (MyButton)e.getSource();
b.setSelected(false);
b.repaint();
}
};</code=java>

Komponenten, die komplizierte Darstellungen ausgeben, sollten repaint() mit den Argumenten aufrufen, welche nur den Bereich definieren, der eine Aktualisierung erfordert. Es ist ein allgemeiner Fehler, immer die keine-Argumente Version zu benutzen, die immer die gesamte Komponente neu zeichnet, was häufig zu nicht notwendigen Malverarbeitungen führt.

===paint() gegen update()===
Warum unterscheiden wir zwischen systemausgelöstem und anwendungsausgelöstem Malen? Weil AWT jeden dieser Fälle etwas anders für heavyweight Komponenten behandelt (der lightweight Fall wird später besprochen), was leider eine Quelle großer Verwirrung ist.

Für heavyweight Komponenten geschehen diese zwei Arten des Zeichnens in zwei unterschiedlichen Wegen, abhängig davon, ob ein Malvorgang systemausgelöst oder anwendungsausgelöst ist.

====systemausgelöstes Malen====
dies ist, wie ein systemausgelöster Malvorgang stattfindet:

# Das AWT stellt fest, daß entweder ein Teil oder die ganze Komponente gemalt werden muß.
# Das AWT veranlasst den Event Dispatch Thread, paint() auf der Komponente aufzurufen.

====anwendungsausgelöstes Malen====
Ein anwendungsausgelöster Malvorgang findet wie folgt statt:

# Das Programm stellt fest, daß entweder ein Teil oder die ganze Komponente in Erwiderung auf eine interne Zustandsänderung neu gezeichnet werden muß.
# Das Programm ruft repaint() auf der Komponente auf, was einen asynchronen Antrag zum AWT registriert, daß diese Komponente neu gezeichnet werden muß.
# Das AWT veranlasst den Event Dispatch Thread, ein update() auf der Komponente aufzurufen. ANMERKUNG: Erfolgen mehrfache repaint() Aufrufe auf einer Komponente bevor der erste Antrag verarbeitet wird, können die mehrfachen Anträge zu einem einzigen Aufruf von update() zusammengefasst werden. Der Algorithmus für die Bestimmung, wann mehrfache Anträge zusammengefasst werden sollten, ist Implementierungsabhängig. Wenn mehrfache Anträge zusammengefasst werden, ist das resultierende Updaterechteck gleich der Vereinigung der Rechtecke, die in den zusammengefassten Anträgen enthalten sind.
# Wenn die Komponente nicht update() überschreibt, löscht die Default-Implementierung von update() den Hintergrund der Komponente (wenn es nicht eine lightweight Komponente ist) und ruft einfach paint() auf.

Da bei der Default-Implementierung das abschließende Resultat dasselbe ist wie bei paint(), verstehen viele Leute den Zweck einer unterschiedlichen update() Methode nicht. Während es zutreffend ist, daß die Default-Implementierung von update() die paint() aufruft, ermöglicht dieser "Updatehaken" einem Programm, den anwendungsausgelösten Malvorgang anders anzufassen, wenn es gewünscht wird. Ein Programm muß annehmen, daß ein Aufruf von paint() andeutet, daß der Bereich, der durch das Cliprechteck vom Graphics definiert wird, "beschädigt" ist und vollständig neu gezeichnet werden muß, gleichwohl ein Aufruf von update() dieses nicht andeutet, was einem Programm ermöglicht, zusätzliches Zeichnen zu tun.

Zusätzliches Zeichnen ("incremental painting") ist nützlich, wenn ein Programm die zusätzliche Darstellung über die vorhandenen Teilstücke dieser Komponente überlagern möchte. Das UpdateDemo Beispiel zeigt ein Programm, das Nutzen aus dem Verwenden von update() zieht, um zusätzliches Zeichnen zu tun:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/UpdateDemo.java UpdateDemo]

In Wahrheit braucht die Mehrheit der GUI Komponenten kein zusätzliches Zeichnen zu tun. So können die meisten Programme die update() Methode ignorieren und einfach paint() überschreiben, um die Komponente in ihrem gegenwärtigen Zustand darzustellen. Das heißt, daß die systemausgelöste und anwendungsausgelöste Darstellung im Wesentlichen für die meisten Implementierungen gleichbedeutend ist.

==Das Malen und die lightweight Komponenten ==
Von der Perspektive des Anwendungsentwicklers, ist die Mal-API im Allgemeinen dieselbe für lightweight und heavyweight Komponenten (das heißt, er überschreibt paint() und ruft repaint() auf, um Updates auszulösen). Jedoch seit AWTs lightweight Komponentenrahmen völlig im allgemeinen [[Java]] Code geschrieben wurde, sind dort einige subtile Unterschiede bezüglich der Weise, wie der Mechanismus für lightweight Komponenten implementiert wird.

===Wie lightweight Komponenten gemalt werden===
Damit eine lightweight Komponente besteht, benötigt sie einen heavyweight Vorfahr in der Containerhierarchie, um einen Platz zum Malen zu haben. Wenn diesem heavyweight Vorfahr gesagt wird, sein Fenster zu malen, muß er den Malaufruf übersetzen in Malaufrufe an alle seine lightweight Nachkommen. Dies wird durch die paint() Methode von '''java.awt.Container''' verarbeitet, welche paint() auf irgendwelchen seiner sichtbaren lightweight Kinder aufruft, die sich mit dem zu malenden Rechteck überschneiden. So ist es für alle Containerunterklassen (lighweight oder heavyweight), welche paint() überschreiben, notwendig, folgendes zu tun:

<code=java> public class MyContainer extends Container {
public void paint(Graphics g) {
// paint my contents first...
// then, make sure lightweight children paint
super.paint(g);
}
}</code=java>

Wenn der Aufruf von super.paint() fehlt, dann werden die lightweight Nachkommen des Containers nicht dargestellt (ein sehr verbreitetes Problem als JDK 1.1 die lightweight Komponenten einführte).

Es ist nützlich anzumerken, daß die Default-Implementierung von Container.update() nicht die Rekursion verwendet, um update() oder paint() auf lightweight Nachkommen aufzurufen. Das heißt, daß irgendeine heavyweight Containerunterklasse, die update() benutzt, um zusätzlichen Zeichnen zu tun, sichergehen muß, daß lightweight Nachkommen wenn nötig rekursiv neu gezeichnet werden. Glücklicherweise benötigen wenige heavyweight Container zusätzliches Zeichnen, also beeinflußt diese Frage die meisten Programme nicht.

===lightweight und systemausgelöstes Malen ===
Der lightweight Rahmencode, der das Fensterdarstellungsverhalten für lightweight Komponenten einführt (sichtbar machen, verstecken, bewegen, die Größe neu bestimmen, usw..), ist völlig in Java geschrieben. Innerhalb der Java Implementierung dieser Funktionen, muß das AWT häufig verschiedenen lightweight Komponenten ausdrücklich erklären, sich zu malen (im Wesentlichen systemausgelöstes Malen, obwohl es nicht mehr vom nativen System ausgeht). Jedoch benutzt der lightweight Rahmen '''repaint()''', um Komponenten zu erklären, sich zu malen, was einen Aufruf von update() anstatt eines Direktaufrufs von paint() ergibt, wie wir oben gesehen haben. Folglich kann systemausgelöstes Zeichnen für lightweight Komponenten zwei Wegen folgen:

* Der systemausgelöste Malantrag entsteht im nativen System (d.h. der heavyweight Vorfahr der lightweight Komponente wird zum ersten Mal sichtbar), was einen Direktaufruf von paint() ergibt.
* Der systemausgelöste Malantrag entsteht im lightweight Rahmen (d.h., die Größe der lightweight Komponente wird neu bestimmt), was einen Aufruf von update() ergibt, der in der Default-Implementierung an paint() weitergeleitet wird.

Dies bedeutet, daß es für lightweight Komponenten '''keine reale Unterscheidung zwischen update() und paint() gibt''', was weiter bedeutet, daß die zusätzliche Zeichnentechnik (incremental painting) nicht für lightweight Komponenten verwendet werden sollte.

===lightweight und Transparenz===
Da lightweight Komponenten den Bildschirmplatz eines heavyweight Vorfahrs "borgen", unterstützen sie die Eigenschaft der Transparenz. Dies funktioniert, weil lightweight Komponenten von hinten nach vorne gemalt werden und folglich, wenn eine lightweight Komponente einige oder all ihre Bits unbemalt läßt, die dahinterliegende Komponente "durchscheint". Dies ist auch der Grund, warum die Default-Implementierung von update() den Hintergrund nicht löscht, wenn die Komponente lightweight ist.

Das LightweightDemo Programmbeispiel zeigt die Transparenzeigenschaft der lightweight Komponenten:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/LightweightDemo.java LightweightDemo]

==Das "intelligente" Malen==
Während das AWT versucht, den Prozeß der Darstellung der Komponenten so leistungsfähig wie möglich zu machen, kann die paint() Implementierung einer Komponente selbst eine bedeutende Auswirkung auf die gesamte Leistung haben. Zwei Schlüsselbereiche, die diesen Prozeß beeinflussen können, sind:

* Die Clipinformationen verwenden, um den Bereich, der dargestellt wird, einzuschränken.
* Internes Wissen über das Layout verwenden, um den Bereich, welche Kinder gemalt werden, einzuschränken (nur lightweight).

Wenn deine Komponente einfach ist -- zum Beispiel, wenn es eine Drucktaste ist -- dann ist sie die Mühe nicht wert, die Darstellung zu bearbeiten, um nur den Teil zu malen, der das Cliprechteck überschneidet; es ist vorzuziehend, die gesamte Komponente zu malen und die Graphics passend einschränken zu lassen. Wenn du jedoch eine Komponente mit komplizierter Ausgabe erzeugt hast, wie eine Textkomponente, dann ist es notwendig, daß dein Code die Clipinformationen gebraucht, um den Umfang der Darstellung einzuschränken.

Weiter, wenn du einen komplizierten lightweight Container schreibst, der zahlreiche Komponenten beherbergt, wo der Container und/oder sein Layoutmanager Informationen über das Layout hat, dann ist er es wert dieses Layoutwissen zu verwenden, um intelligenter in der Bestimmung zu sein, welche der Kinder gemalt werden müssen. Die Default-Implementierung von Container.paint() schaut einfach der Reihe nach durch die Kinder und prüft die Sichtbarkeit und Überschneidung -- ein Vorgang, der mit bestimmten Layouts unnötigerweise aufwendig sein kann. Zum Beispiel, wenn ein Container die Komponenten in einem Rasterfeld 100x100 auslegt, dann könnte diese Rasterfeldinformation verwendet werden, schneller festzustellen, welche von jenen 10000 Komponenten das Cliptechteck überschneiden und wirklich gemalt werden müssen.

==AWT Malrichtlinien ==
Das AWT stellt eine einfache callback API für das Malen von Komponenten zur Verfügung. Wenn du sie verwendest, treffen die folgenden Richtlinien zu:

# Für die meisten Programme sollte aller Malcode innerhalb des Bereichs der paint() Methode der Komponente gesetzt werden.
# Programme können einen zukünftigen Aufruf von paint() auslösen, indem sie repaint() aufrufen, aber sie sollten nicht paint() direkt aufrufen.
# Bei Komponenten mit komplizierter Ausgabe, sollte repaint() mit Argumenten aufgerufen werden, die nur das Rechteck definieren, das aktualisieren muß, anstatt der keine-Argumente Version, die die gesamte Komponente veranlasst neu gezeichnet zu werden.
# Da ein Aufruf von repaint() zuerst einen Aufruf von update() ergibt, der in der Default-Implementierung an paint() weitergeleitet wird, können heavyweight Komponenten update() überschreiben, um zusätzliches Zeichnen (incremental painting) zu tun, wenn es gewünscht wird (lightweight Komponenten unterstützen nicht das zusätzliche Zeichnen).
# Erweiterungen von java.awt.Container, die paint() überschreiben, sollten immer super.paint() aufrufen, um sicherzustellen, dass die Kinder gemalt werden.
# Komponenten mit komplizierter Ausgabe sollten intelligenten Gebrauch vom Cliprechteck machen, um den Malvorgang auf den Bereich zu beschränken, der sich mit dem Clipbereich überschneidet.

=Malen in Swing=
Swing beginnt mit AWTs grundlegendem Malmodell und erweitert es, um die Leistung zu maximieren und die Erweiterbarkeit zu verbessern. Wie AWT, so unterstützt auch Swing den Malcallback und den Gebrauch von repaint(), um Updates auszulösen. Zusätzlich gibt Swing eingebaute Unterstützung für Doppelpufferung sowie Änderungen, um die zusätzliche Swing Struktur zu unterstützen (wie Ränder und der UI Delegate). Und schließlich stellt Swing die RepaintManager API für jene Programme zur Verfügung, die den Malmechanismus weiter anpassen möchten.

==Unterstützung für Doppelpufferung ==
Eine der bemerkenswertesten Eigenschaften von Swing ist, daß es die Unterstützung für Doppelpufferung direkt ins Toolkit einbaut. Das geschieht durch die Bereitstellung der "doubleBuffered" Eigenschaft in '''javax.swing.JComponent:
'''
<code=java> public boolean isDoubleBuffered()
public void setDoubleBuffered(boolean o)</code=java>

Die Doppelpufferung von Swing benutzt einen einzigen offscreen Puffer pro Containerhierarchie (normalerweise einen pro Fenster) wo die Doppelpufferung eingeschaltet worden ist. Obgleich diese Eigenschaft pro Komponente eingeschaltet werden kann, ergibt ihre Einschaltung in einem bestimmten Container den Effekt, dass alle lightweight Komponenten darunter in dem offscreen Puffer dargestellt werden, unabhängig davon wie die individuelle "doubleBuffered" Eigenschaft eingestellt ist.

Der Default-Wert dieser Eigenschaft ist bei allen Swingkomponenten auf "true" gesetzt. Aber die Einstellung, die wirklich zählt, ist in JRootPane, weil diese Einstellung effektiv Doppelpufferung für alles darunter einschaltet. In den meisten Fällen brauchen Swingprogramme nichts zu tun in Bezug auf Doppelpufferung, ausgenommen, zu entscheiden, ob sie ein- oder ausgeschaltet sein sollte (und für eine flackerfreie GUI wirst du wünschen, dass sie eingeschaltet ist!). Swing stellt sicher, daß die passende Art des Graphics Objektes (offscreen Bild Graphics für Doppelpufferung, sonst die original Graphics) der Komponente übergeben wird, so braucht die Komponente lediglich mit ihm zu zeichnen. Dieser Mechanismus wird später in diesem Artikel ausführlicher erklärt (im Abschnitt über die Malverarbeitung).

==Zusätzliche Maleigenschaften ==
Swing stellt einige zusätzliche Eigenschaften von JComponent vor, um die Leistungsfähigkeit der internen Malalgorithmen zu verbessern. Diese Eigenschaften wurden eingeführt, um sich mit den folgenden zwei Fragen zu beschäftigen, die das Zeichnen von lightweight Komponenten zu einem kostspieligen Vorgang machen können:

* '''Transparenz''': Wenn eine lightweight Komponente gemalt wird, ist es möglich, daß die Komponente nicht alle ihre Bits malt, wenn sie teilweise oder ganz transparent ist; das heißt, daß, wann immer sie neu gezeichnet wird, das was dahinter liegt zuerst neu gezeichnet werden muss. Das erfordert vom System, die Containerhierarchie hinaufzugehen um den ersten zugrundeliegenden heavyweight Vorfahr zu finden, von dem der hinten-nach-vorne Malvorgang ausgehen soll.
* '''Überlappende Komponenten''': Wenn eine lightweight Komponente gemalt wird, ist es möglich, daß irgendeine andere lightweight Komponente sie teilweise verdeckt; das heißt, daß, wann immer die ursprüngliche lightweight Komponente gemalt wird, alle möglichen Komponenten, die die ursprüngliche Komponente überdecken (wo das Cliprechteck sich mit dem überlappenden Bereich schneidet), auch teilweise neu gezeichnet werden müssen. Dies erfordert vom System, bei jedem Malvorgang viel von der Containerhierarchie zu durchqueren und auf überlappende Komponenten zu überprüfen.

===Die Opazität===
Um im Fall von undurchlässigen Komponenten die Leistung zu verbessern, fügt Swing eine "opaque" Lese-Schreibeigenschaft zu javax.swing.JComponent hinzu:

<code=java> public boolean isOpaque()
public void setOpaque(boolean o)</code=java>

Die Einstellungen sind:

*true: Die Komponente ist damit einverstanden, alle ihre Bits zu malen, die innerhalb ihrer rechteckigen Grenzen enthalten sind.
*false: Der Komponente gibt keine Garantien über das Malen aller Bits innerhalb ihrer rechteckigen Grenzen.

Die "opaque" Eigenschaft läßt das Malsystem von Swing ermitteln, ob ein repaint Antrag auf einer bestimmten Komponente zusätzliche repaint Anträge der dahinter liegenden Vorfahren erfordert oder nicht. Der Default-Wert der "opaque" Eigenschaft für jede standard Swingkomponente wird durch das gegenwärtige Look and Feel UI Objekt eingestellt. Der Wert ist für die meisten Komponenten "true".

Einer der allgemeinsten Fehler, die Komponentenimplementierungen machen, ist, daß sie die "opaque" Eigenschaft auf "true" belassen, und dennoch den Bereich nicht vollständig darstellen, der durch ihre Grenzen definiert ist, was gelegentliche Unreinheiten in den nicht dargestellten Bereichen ergibt. Wenn eine Komponente entworfen wird, sollte sorgfältig überlegt werden, wie die "opaque" Eigenschaft zu behandeln ist, sowohl um sicherzustellen, daß Transparenz klug benutzt wird, da sie mehr Darstellungszeit kostet, und daß die Übereinkunft mit dem Malsystem eingehalten wird.

Die Bedeutung der "opaque" Eigenschaft wird häufig mißverstanden. Manchmal wird sie verstanden als "den Hintergrund der Komponente transparent machen". Jedoch ist dies nicht die strenge Deutung der Opazität in Swing. Einige Komponenten, wie eine Drucktaste, können die "opaque" Eigenschaft auf false setzen, um der Komponente eine nicht-rechteckige Form zu geben oder Raum um die Komponente herum zu behalten für vorübergehende Sichtbarmachungen, wie eine Fokusanzeige. In diesen Fällen ist die Komponente nicht opaque, aber der Hauptteil seines Hintergrundes wird dennoch ganz ausgefüllt!

Wie vorher definiert, ist die "opaque" Eigenschaft hauptsächlich ein Vertrag mit dem Repaintsystem. Wenn eine Komponente auch die "opaque" Eigenschaft benutzt, um zu definieren, wie Transparenz an den Sichtbarmachungen einer Komponente angewendet wird, dann sollte dieser Gebrauch von der Eigenschaft dokumentiert werden. (es kann für einige Komponenten vorzuziehen sein, zusätzliche Eigenschaften zu definieren, um die Sichtaspekte davon zu steuern, wie Transparenz angewendet wird. Z.B. hat javax.swing.AbstractButton die ContentAreaFilled Eigenschaft zu diesem Zweck.)

Eine andere Frage, die eine Anmerkung wert ist, ist wie sich Opazität auf die Randeigenschaft einer Swingkomponente bezieht. Der Bereich, der durch ein Randobjekt auf einer Komponente dargestellt wird, wird noch als ein Teil der Geometrie dieser Komponente betrachtet. Das heißt, daß, wenn eine Komponente "opaque" ist, sie immer noch für das Füllen des Bereichs verantwortlich ist, der durch den Rand besetzt wird. (der Rand überlagert dann einfach seine Darstellung über die undurchlässige Komponente).

Wenn eine dahinter liegende Komponente durch den Randbereich einer Komponente durchscheinen soll -- das heißt, wenn der Rand Transparenz unterstützt indem isBorderOpaque() "false" zurückgibt (z.B. EmptyBorder oder LineBorder mit roundedCorners) -- dann, muß die Komponente sich selbst auch als nicht opaque definieren und sicherstellen dass sie den Randbereich nicht übermalt.

Siehe auch: http://forum.java.sun.com/thread.jspa?messageID=10329261&start=1

==="optimiert" zeichnen===
Die Frage des Zeichnens von überlappenden Komponenten ist heikler. Selbst wenn keiner der direkten Geschwister einer Komponente diese überdeckt, ist es immer möglich, daß ein Nichtvorfahr Verwandter (wie ein "Vetter" oder "Tante") sie verdecken könnte. In solch einem Fall könnte das repaint einer einzelnen Komponente innerhalb einer komplizierten Hierarchie eine Menge Treewalking erfordern, um 'korrektes' Zeichnen sicherzustellen. Um unnötiges Durchqueren zu verringern, fügt Swing die read-only Eigenschaft "isOptimizedDrawingEnabled" zu javax.swing.JComponent hinzu:

<code=java> public boolean isOptimizedDrawingEnabled()</code=java>

die Einstellungen sind:

* true: Die Komponente zeigt an, daß keine seiner direkten Kinder sich überlappen.
* false: Die Komponente gibt keine Garantie, ob seine direkten Kinder sich überlappen oder nicht.

Indem es die Eigenschaft "isOptimizedDrawingEnabled" überprüft, kann Swing schnell seine Suche nach überlappenden Komponenten zur repaint Zeit eingrenzen.

Da "isOptimizedDrawingEnabled" eine read-only Eigenschaft ist, ist also der einzige Weg, wie Komponenten den Default-Wert ändern können, die Klasse zu erweitern und diese Methode zu überschreiben, um den gewünschten Wert zurückzugeben. Alle standard Swingkomponenten geben "true" für diese Eigenschaft zurück, außer JLayeredPane, JDesktopPane und JViewPort. Wenn wir also z.B. ein JPanel mit einem Layout haben, das überlappende Komponenten zulässt (wie "OverlayLayout"), dann ist es gewöhnlich notwendig, JPanel zu erweitern und isOptimizedDrawingEnabled() zu überschreiben, um "false" zurückzugeben.

==Die Malmethoden ==
Die Richtlinien, die auf AWTs lightweight Komponenten zutreffen, treffen auch auf Swingkomponenten zu -- zum Beispiel wird paint() aufgerufen, wenn es Zeit ist darzustellen -- außer daß Swing den paint() Aufruf in drei verschiedene Methoden unterteilt, die in folgender Reihenfolge aufgerufen werden:

<code=java> protected void paintComponent(Graphics g)
protected void paintBorder(Graphics g)
protected void paintChildren(Graphics g)</code=java>

Swingprogramme sollten '''paintComponent()''' anstelle von paint() überschreiben. Obgleich die API es erlaubt, gibt es im Allgemeinen keinen Grund paintBorder() oder paintChildren() zu überschreiben (und wenn du es tust, sei dir sicher was du tust!). Dies macht es den Programmen einfacher, nur den Teil des Zeichnens zu überschreiben, den sie erweitern müssen. Z.B. löst dies das AWT Problem, das vorher erwähnt wurde, wo die Unterlassung, super.paint() aufzurufen alle lightweight Kinder am Erscheinen hinderte.

Das SwingPaintDemo Programmbeispiel zeigt den einfachen Gebrauch der paintComponent() callback Methode von Swing:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/SwingPaintDemo.java SwingPaintDemo]

===Das Malen und der UI Delegate ===
Die meisten standard Swingkomponenten haben ihren Look and Feel implementiert durch getrennte look-and-feel Objekte (genannt "UI Beauftragte"), für die steckbare Look and Feel Eigenschaft von Swing. Das heißt, daß das meiste oder das ganze Zeichnen der standard Komponenten dem UI Delegate übergeben wird und dies geschieht folgendermaßen:

# paint() ruft paintComponent() auf.
# Wenn die "ui" Eigenschaft nicht "null" ist, ruft paintComponent() ui.update() auf.
# Wenn die "opaque" Eigenschaft der Komponente "true" ist, füllt ui.update() den Hintergrund der Komponente mit der Hintergrundfarbe und ruft ui.paint() auf.
# ui.paint() stellt den Inhalt der Komponente dar.

Das heißt, daß Unterklassen von Swingkomponenten, die einen UI Delegate haben (im Gegensatz zu direkten Unterklassen von JComponent), super.paintComponent() innerhalb ihrer paintComponent Überschreibung aufrufen sollten:

<code=java> public class MyPanel extends JPanel {
protected void paintComponent(Graphics g) {
// Let UI delegate paint first
// (including background filling, if I'm opaque)
super.paintComponent(g);
// paint my contents next....
}
}</code=java>

Wenn aus irgendeinem Grund die Erweiterung der Komponente nicht zulassen möchte, daß der UI Delegate malt (wenn sie zum Beispiel die sichtbaren Elemente der Komponente vollständig ersetzt), kann sie den Aufruf von super.paintComponent() weglassen, aber sie ist dann für das Ausfüllen ihres eigenen Hintergrundes verantwortlich, wenn die "opaque" Eigenschaft "true" ist, wie im Abschnitt über die "opaque" Eigenschaft besprochen wurde.

==Malverarbeitung ==
Swing verarbeitet "repaint" Anträge in einer etwas anderen Weise als AWT, obgleich das Resultat für den Anwendungsprogrammierer im Wesentlichen dasselbe ist -- paint() wird aufgerufen. Swing tut dies, um seine RepaintManager API zu unterstützen (wird später besprochen), sowie zur Verbesserung der Malleistung. In Swing kann das Malen zwei Wegen folgen, wie unten beschrieben:

(a) Der Malantrag entsteht im ersten heavyweight Vorfahr (normalerweise JFrame, JDialog, JWindow oder JApplet):

# der "event dispatching thread" ruft paint() für diesen Vorfahr auf,
# die Default-Implementierung von Container.paint() ruft rekursiv paint() auf allen lightweight Nachkommen auf,
# wenn die erste Swingkomponente erreicht wird, macht die Default-Implementierung von '''JComponent.paint()''' folgendes:
## wenn die "doubleBuffered" Eigenschaft der Komponente "true" ist und Doppelpufferung ist im RepaintManager der Komponente eingeschaltet, wandelt sie das Graphics Objekt um zu einem passenden offscreen Graphics.
## ruft paintComponent() auf (und übergibt offscreen Graphics, wenn "doubleBuffered")
## ruft paintBorder() auf (und übergibt offscreen Graphics, wenn "doubleBuffered")
## ruft paintChildren() auf (und übergibt offscreen Graphics, wenn "doubleBuffered") welche die Eigenschaften "clip", "opaque" und "optimizedDrawingEnabled" verwendet, um genau festzustellen, für welche Nachkommen, "paint()" rekursiv aufzurufen ist.
## wenn die "doubleBuffered" Eigenschaft der Komponente "true" ist und Doppelpufferung ist im RepaintManager der Komponente eingeschaltet, kopiert sie das offscreen Bild auf die Komponente unter Benutzung des ursprünglichen onscreen Graphics Objektes.

::ANMERKUNG: die JComponent.paint() Schritte #1 und #5 werden in den rekursiven Aufrufen von paint() übersprungen (in paintChildren(), beschrieben in Schritt #4) weil alle lightweight Komponenten innerhalb einer Swingfensterhierarchie dasselbe offscreen Bild für Doppelpufferung teilen.

(b) Der Malantrag entsteht durch einen Aufruf von repaint() auf einer Erweiterung von javax.swing.JComponent:
# JComponent.repaint() registriert einen asynchronen repaint Antrag beim RepaintManager der Komponente, der invokeLater() benutzt, um einen Runnable entstehen zu lassen, der den Antrag später auf dem "event dispatching thread" verarbeitet.
# der Runnable wird auf dem "event dispatching thread" ausgeführt und er veranlasst den RepaintManager der Komponente, '''paintImmediately()''' auf der Komponente aufzurufen, die folgendes tut:
## verwendet das Cliprechteck und die Eigenschaften "opaque" und "optimizedDrawingEnabled", um die 'root' Komponente festzustellen, von der aus der Malvorgang anfangen muß (um sich um Transparenz und möglicherweise überlappende Komponenten kümmern zu können).
## wenn die "doubleBuffered" Eigenschaft der 'root' Komponente "true" ist und Doppelpufferung ist im RepaintManager vom 'root' eingeschaltet, wandelt sie das Graphics Objekt um zu einem passenden offscreen Graphics.
## ruft paint() auf der 'root' Komponente auf (was die JComponent.paint() Schritte #2-4 oben unter (a) durchführt), und verursacht so, daß alles unter dem 'root' gemalt wird, was sich mit dem Cliprechteck überschneidet.
## wenn die "doubleBuffered" Eigenschaft der 'root' Komponente "true" ist und Doppelpufferung ist im RepaintManager der 'root' Komponente eingeschaltet, kopiert sie das offscreen Bild auf die Komponente unter Benutzung des ursprünglichen onscreen Graphics Objektes.

::ANMERKUNG: wenn mehrfache Aufrufe von repaint() auf einer Komponente oder irgendwelchen seiner Swingvorfahren auftreten, bevor der repaint Antrag verarbeitet wird, können jene mehrfachen Anträge in einen einzigen Callback von paintImmediately() auf der obersten Swingkomponente zusammengefasst werden, auf der repaint() aufgerufen wurde. Z.B. wenn ein JTabbedPane eine JTable enthält und beide Aufrufe von repaint() absenden, bevor irgendwelche anstehenden Anträge dieser Hierarchie verarbeitet werden, ist das Resultat ein einziger Aufruf von paintImmediately() auf dem JTabbedPane, was veranlasst, daß paint() auf beiden Komponenten durchgeführt wird.

Das heißt, daß update() für SwingKomponenten nie aufgerufen wird.

Obgleich repaint() einen Aufruf von paintImmediately() ergibt, gilt es nicht als "Malcallback" , und Malcode sollte nicht innerhalb einer paintImmediately() gesetzt werden. Tatsächlich gibt es im Allgemeinen überhaupt keinen Grund, paintImmediately() zu überschreiben.

===Synchrones Zeichnen===
Wie im vorhergehenden Abschnitt beschrieben, dient paintImmediately() als Ausgangspunkt um einer einzelnen Swingkomponente zu sagen, sich zu malen und zu überprüfen, ob alles erforderliche Zeichnen passend geschieht. Diese Methode kann auch für synchrone Malanträge verwendet werden, wie sein Name andeutet, was manchmal bei Komponenten erfordert ist, die sicherstellen müssen, daß ihr Aussehen in Echtzeit mit ihrem internen Zustand 'Schritt hält' (z.B. gilt dies für das JScrollPane während eines Rollvorgangs).

Programme sollten diese Methode nicht direkt aufrufen, es sei denn, es gibt eine tatsächliche Notwendigkeit zum Zeichnen in Echtzeit. Das ist so, '''weil durch das asynchrone repaint() mehrfache überlappende Anträge leistungssteigernd zusammengefasst werden''', während das bei Direktaufrufen von paintImmediately() nicht geschieht. Zusätzlich ist die Richtlinie für das Aufrufen dieser Methode, daß sie auf dem "event dispatching thread" aufgerufen werden muß; es ist keine API, die für den "multi-threading" Ihres Malcodes bestimmt ist! Für mehr Einzelheiten über das "single-threaded" Modell von Swing, siehe den archivierten Artikel "Threads and Swing" :

[http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html Threads and Swing]

==Der RepaintManager ==
Der Zweck der Swingklasse "RepaintManager" ist, die Leistungsfähigkeit der repaint Verarbeitung auf einer Swing Containerhierarchie zu maximieren, und auch zur Implementierung des "revalidation" Mechanismus von Swing (letzteres wird das Thema für einen weiteren Artikel sein, siehe auch: [http://www.java-forum.org/de/viewtopic.php?p=431845#431845 Validierung mit Swing]). Sie implementiert den repaint Mechanismus, indem sie alle repaint Anträge von Swing Komponenten abfängt (also werden sie nicht mehr durch das AWT verarbeitet) und ihren eigenen Zustand beibehält in Bezug auf das, was aktualisiert werden muss (bekannt als "dirty regions", also "verschmutzte Bereiche"). Schließlich benutzt sie invokeLater(), um die anstehenden Anträge auf dem "event dispatching thread" zu verarbeiten, wie im Abschnitt "Malverarbeitung" beschrieben (Option b). [Der RepaintManager wird eine Serie von Malanträgen möglichst zusammenfassen, wenn (und nur wenn) der "Anführer" der Serie mit invokeLater verschickt wurde, aber noch nicht auf dem EDT verarbeitet wurde.]

Für die meisten Programme kann der RepaintManager als Teil des internen Systems von Swing angesehen werden und praktisch ignoriert werden. Jedoch liefert seine API den Programmen die Möglichkeit einer feineren Steuerung von bestimmten Aspekten des Zeichnens.

===Der "gegenwärtige" RepaintManager ===
Der RepaintManager ist entworfen, um dynamisch ausgewechselt zu werden, obgleich es durch die Default-Implementierung eine einzige Instanz gibt. Die folgenden statischen Methoden lassen Programme auf den "gegenwärtigen" RepaintManager zugreifen und ihn ersetzen:

<code=java> public static RepaintManager currentManager(Component c)
public static RepaintManager currentManager(JComponent c)
public static void setCurrentManager(RepaintManager aRepaintManager)</code=java>

===Den "gegenwärtigen" RepaintManager ersetzen===
Ein Programm würde den RepaintManager global erweitern und ersetzen, indem es folgendes tut:

<code=java> RepaintManager.setCurrentManager(new MyRepaintManager());</code=java>

Du kannst dir RepaintManagerDemo ansehen als ein einfaches lauffähiges Beispiel für die Installation von einem RepaintManager, der Informationen ausdruckt über das, was neu gezeichnet wird:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/RepaintManagerDemo.java RepaintManagerDemo]

Ein interessanterer Grund für das Erweitern und das Ersetzen des RepaintManagers wäre die Art und Weise zu verändern, wie repaint Anträge verarbeitet werden. Zur Zeit ist der interne Zustand, der durch die Default-Implementierung benutzt wird, um schmutzige Regionen aufzuspüren, "package privat" und folglich nicht durch Unterklassen zugänglich. Jedoch können Programme ihre eigenen Mechanismen für das Aufspüren von schmutzigen Regionen und für das Zusammenfassen von repaint Anträgen einführen, indem sie die folgenden Methoden überschreiben:

<code=java> public synchronized void addDirtyRegion(JComponent c, int x, int y, int w, int h)
public Rectangle getDirtyRegion(JComponent aComponent)
public void markCompletelyDirty(JComponent aComponent)
public void markCompletelyClean(JComponent aComponent) {</code=java>

Die addDirtyRegion() Methode ist die, die aufgerufen wird, wenn repaint() auf einer Swingkomponente aufgerufen wird, und kann folglich angespannt werden, um alle repaint Anträge abzufangen. Wenn ein Programm diese Methode überschreibt (und nicht super.addDirtyRegion() aufruft), dann wird es dafür verantwortlich, invokeLater() zu benutzen, um einen Runnable auf die "EventQueue" zu setzen, der paintImmediately() auf einer passenden Komponente aufruft (Übersetzung: nicht für Leute mit schwachem Herzen).

===Globale Steuerung der Doppelpufferung===
Der RepaintManager stellt eine API zur Verfügung, um die Doppelpufferung global zu ermöglichenden und zu sperren:

<code=java> public void setDoubleBufferingEnabled(boolean aFlag)
public boolean isDoubleBufferingEnabled()</code=java>

Während der Verarbeitung eines Malvorgangs wird diese Eigenschaft innerhalb JComponent überprüft, um festzustellen, ob man einen offscreen Puffer für die Darstellung verwendet. Diese Eigenschaft hat den Default-Wert "true", aber die Programme, die Doppelpufferung für alle Swingkomponenten global sperren möchten, können folgendes tun:

<code=java> RepaintManager.currentManager(mycomponent).setDoubleBufferingEnabled(false);</code=java>

Anmerkung: da die Default-Implementierung von Swing einen einzigen RepaintManager instanziert, ist das "mycomponent" Argument irrelevant.

==Swing Malrichtlinien ==
Swingprogramme sollten diese Richtlinien verstehen, wenn Malcode geschrieben wird:

# Für Swingkomponenten wird immer ''paint()'' aufgerufen als Ergebnis sowohl von systemausgelösten als auch von anwendungsausgelösten Malanträgen; ''update()'' wird nie auf Swingkomponenten aufgerufen.
# Programme können einen zukünftigen Aufruf von ''paint()'' auslösen, indem sie ''repaint()'' aufrufen, aber sie sollten ''paint()'' nicht direkt aufrufen.
# Auf Komponenten mit komplizierter Ausgabe, sollte ''repaint()'' mit Argumenten aufgerufen werden, die nur das Rechteck, das aktualisieren muß, definieren, und nicht die keine-Argumente-Version, die die gesamte Komponente veranlasst, neu gezeichnet zu werden.
# Die Swing Implementierung von paint() unterteilt den Aufruf in 3 verschiedene callback Methoden:
#* ''paintComponent()'': Erweiterungen von Swingkomponenten, die ihren eigenen Malcode einführen möchten, sollten diesen Code innerhalb des Bereichs der Methode paintComponent() setzen (nicht innerhalb von paint()).
#* ''paintBorder()''
#* ''paintChildren()''
# Swing stellt zwei Eigenschaften vor, um die Malleistung zu maximieren:
#*''opaque'': malt die Komponente alle ihre Bits oder nicht?
#*''optimizedDrawingEnabled'': können irgendwelche der Kinder dieser Komponente sich überschneiden?
# Wenn die ''opaque'' Eigenschaft einer Swingkomponente auf ''true'' gesetzt wird, dann erklärt sie sich damit einverstanden, alle Bits zu malen, die innerhalb ihrer Grenzen enthalten sind (dies schließt das Löschen ihres eigenen Hintergrundes innerhalb von ''paintComponent()'' ein), andernfalls können Bilschirmunreinheiten auftreten.
# Das Setzen entweder von ''opaque'' oder ''optimizedDrawingEnabled'' auf ''false'' für eine Komponente verursacht mehr Verarbeitung bei jedem Malvorgang, folglich empfehlen wir vernünftigen Gebrauch von Transparenz und überlappenden Komponenten zu machen.
# Erweiterungen von Swingkomponenten, die ''UI Delegates'' haben (einschließlich ''JPanel''), sollten gewöhnlich ''super.paintComponent()'' innerhalb ihrer eigenen ''paintComponent()'' Implementierung aufrufen. Da der ''UI Delegate'' die Verantwortung für das Löschen des Hintergrundes auf undurchlässigen Komponenten hat, kümmert er sich um #6.
# Swing unterstützt eingebaute Doppelpufferung über die ''doubleBuffered'' Eigenschaft von ''JComponent'', und ihr Default-Wert ist ''true'' für alle Swingkomponenten, gleichwohl das Setzen auf ''true'' auf einem Swingcontainer den allgemeinen Effekt hat, sie für alle lightweight Nachkommen dieses Containers einzuschalten, unabhängig von ihren einzelnen Einstellungen.
# Es wird ausdrücklich empfohlen, daß Doppelpufferung für alle Swingkomponenten ermöglicht wird.
# Komponenten, die komplizierte Ausgaben darstellen, sollten intelligenten Gebrauch vom Cliprechteck machen, um die Malvorgänge auf diejenigen zu beschränken, die sich mit dem Clipbereich schneiden.

=Zusammenfassung =
Beide, AWT und Swing, liefern APIs, um es den Programmen einfach zu machen, ihren Inhalt korrekt am Bildschirm darzustellen. Obgleich wir empfehlen, daß Entwickler für die meisten GUI Bedürfnisse Gebrauch von Swing machen, ist es nützlich, AWTs Malmechanismus zu verstehen, weil derjenige von Swing darauf aufbaut.

Um die beste Leistung von diesen APIs zu erhalten, müssen Anwendungsprogramme die Verantwortung dafür übernehmen, die in diesem Dokument umrissenen Richtlinien zu befolgen.

[[Kategorie:Java]]
[[Kategorie:Tutorials (Java)]]
[[Kategorie:Swing]]

Malen in AWT und Swing

2013-01-12T06:31:16Z

AndreUhres: /* Malen in AWT und Swing */

__TOC__
=Malen in AWT und Swing=
Guter Malcode ist der Schlüssel zu einer leistungsfähigen Anwendung.

Von Amy Fowler.

[http://java.sun.com/products/jfc/tsc/articles/painting/ Copyright 1994-2008 Sun Microsystems, Inc.]

Übersetzung: André Uhres (Ich habe bei Sun die Erlaubnis angefragt, diesen Artikel zu übersetzen und hier zu veröffentlichen)

*HINWEIS vom Übersetzer: Zum Einstieg in das Malen mit Swing ist auch der folgende kurze und praxisorientierte Artikel gut geeignet: [[Malen in Swing Teil 1: der grundlegende Mechanismus]]

In einem graphischen System ist normalerweise ein Fensterdarstellungstoolkit dafür verantwortlich, einen Rahmen zur Verfügung zu stellen, der es relativ einfach macht, auf einer graphischen Benutzerschnittstelle (GUI) die richtigen Bits zur richtigen Zeit darzustellen.
Sowohl [[AWT]] (abstraktes Fensterdarstellungstoolkit) als auch [[Swing]] liefern solch einen Rahmen.
Aber die [[API]]s, die ihn verwirklichen, werden von manchen [[Entwickler]]n nicht gut verstanden -- ein Problem, das zu Programmen geführt hat, die nicht so leistungsfähig sind, wie sie sein könnten.

Dieser Artikel beschreibt die AWT und Swing Malmechanismen im Einzelnen. Sein Zweck ist, Entwicklern zu helfen, korrekten und leistungsfähigen GUI Malcode zu schreiben. Während der Artikel die allgemeinen Malmechanismen umfaßt (wo und wann man darstellt), erklärt er nicht, wie man die Swing Graphiken APIs benutzt, um korrekte Graphiken darzustellen. Um zu erlernen wie man nette Graphiken macht, besichtigen Sie bitte die [http://docs.oracle.com/javase/tutorial/2d/index.html Java 2D Website].

=Entwicklung des Swing Malsystems=

Als die ursprüngliche AWT API für [[JDK]] 1.0 entwickelt wurde, gab es nur heavyweight Komponenten ("heavyweight" bedeutet, daß die Komponente ihr eigenes undurchlässiges natives Fenster hat). Dies erlaubte es dem AWT, sich voll auf das Maluntersystem der nativen Plattform zu stützen. Dieser Entwurf kümmerte sich um Einzelheiten wie Beschädigungserkennung, Clipberechnung und Z-Einrichtung.

Mit der Einführung der lightweight Komponenten in JDK 1.1 (eine "lightweight" Komponente ist eine, die das native Fenster ihres nächsten heavyweight Vorfahrs wiederverwendet), mußte das AWT das Malen für lightweight Komponenten im gemeinsamen Java Code einführen. Somit gibt es feine Unterschiede bezüglich des Malvorgangs für heavyweight und lightweight Komponenten. Nach dem JDK 1.1, als das Swing Toolkit freigegeben wurde, stellte dieses seine eigenen Malmechanismen vor. In den meisten Fällen ähnelt und beruht der Swing Malmechanismus auf dem AWT. Aber er führt auch einige Unterschiede bezüglich der Mechanismen ein, sowie neue APIs, mit denen die Anwendungen den Malvorgang einfacher anpassen können.

=Malen in AWT=

Zu verstehen, wie die Mal-API von AWT arbeitet, hilft zu erkennen, was einen Malvorgang in einer Fensterdarstellungsumgebung auslöst. In AWT gibt es zwei Arten von Malvorgängen: systemausgelöstes Malen und anwendungsausgelöstes Malen.

==Systemausgelöstes Malen==

In einem systemausgelösten Malvorgang, bittet das System eine Komponente, ihren Inhalt darzustellen, normalerweise aus einem der folgenden Gründe:

* Die Komponente wird zum erstenmal sichtbar auf dem [[Bildschirm]] abgebildet.
* Die Komponente wird in der Größe verändert.
* Die Komponente wurde beschädigt und muß repariert werden (zum Beispiel wurde etwas verschoben, das vorher die Komponente verdeckte, und ein vorher verdeckter Teil der Komponente wird sichtbar).

==Anwendungsausgelöstes Malen==

Bei einem anwendungsausgelösten Malvorgang entscheidet die Komponente, daß sie ihren Inhalt aktualisieren muß, weil sich ihr interner [[Zustand]] geändert hat. Beispiel: ein Button erkennt, daß eine [[Maus]]taste betätigt worden ist und stellt fest, daß er einen "niedergedrückten" Button malen muß.

==Die paint Methode==

Ungeachtet dessen, wie ein Malantrag ausgelöst wird, benutzt das AWT einen "callback" ("Wiederholungsbesuch") Mechanismus zum Zeichnen, und dieser Mechanismus ist derselbe für heavyweight und lightweight Komponenten. Das heißt, daß ein [[Programm]] den Darstellungscode der [[Komponente]] innerhalb einer bestimmten überschriebenen [[Methode]] setzen sollte, und das [[Toolkit]] ruft diese Methode auf, wenn es Zeit ist zu malen. Die zu überschreibende Methode ist in '''java.awt.Component''':

<code=java>public void paint(Graphics g)</code=java>

Wenn AWT diese Methode aufruft, ist der Parameter "Graphics g" mit dem passenden Zustand für das Zeichnen auf dieser bestimmten Komponente vorkonfiguriert:

* Die Farbe des Graphics Objektes wird auf die foreground-Eigenschaft der Komponente eingestellt.
* Die Schriftart des Graphics Objektes wird auf die font-Eigenschaft der Komponente eingestellt.
* Die "translation" des Graphics Objektes wird so eingestellt, daß die Koordinate (0,0) die obere linke Ecke der Komponente darstellt.
* Das "clip"-Rechteck des Graphics Objektes wird auf den Bereich der Komponente eingestellt, der neu gezeichnet werden muss.

Programme müssen dieses Graphics Object verwenden (oder ein von ihm abgeleitetes) um die Oberfläche darzustellen. Sie sind frei, den Zustand des Graphics Objektes so zu ändern, wie es benötigt wird.
Hier ist ein einfaches Beispiel von einem paint callback, der einen gefüllten Kreis innerhalb einer Komponente darstellt:

<code=java> public void paint(Graphics g) {
// Dynamically calculate size information
Dimension size = getSize();
// diameter
int d = Math.min(size.width, size.height);
int x = (size.width - d)/2;
int y = (size.height - d)/2;

// draw circle (color already set to foreground)
g.fillOval(x, y, d, d);
g.setColor(Color.black);
g.drawOval(x, y, d, d);
}</code=java>

Entwickler, die neu bei AWT sind, werden einen Blick auf das PaintDemo Beispiel werfen wollen, das ein lauffähiges Programmbeispiel liefert, wie man den paint callback in einem AWT Programm verwendet:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/PaintDemo.java PaintDemo]

Im allgemeinen sollten Programme es vermeiden, darstellenden Code an irgendeinen Punkt zu setzen, wo er von außerhalb des Bereichs der paint callback Methode aufgerufen werden könnte. Warum? Weil solcher Code manchmal aufgerufen werden kann, wenn es nicht angebracht ist zu malen -- zum Beispiel bevor die Komponente sichtbar ist oder Zugang zu einem gültigen Graphics Objekt hat. Es wird nicht empfohlen, daß Programme paint() direkt aufrufen.

Um anwendungsausgelöstes Malen zu ermöglichen, liefert das AWT die folgenden '''java.awt.Component''' Methoden, damit Programme einen asynchronen Malvorgang anfragen können:

<code=java> public void repaint()
public void repaint(long tm)
public void repaint(int x, int y, int width, int height)
public void repaint(long tm, int x, int y, int width, int height)</code=java>

Der folgende Code zeigt ein einfaches Beispiel von einem MouseListener, der repaint() benutzt, um Updates auf einer theoretischen Taste auszulösen, wenn die Maus gedrückt und losgelassen wird:

<code=java> MouseListener l = new MouseAdapter() {
public void mousePressed(MouseEvent e) {
MyButton b = (MyButton)e.getSource();
b.setSelected(true);
b.repaint();
}

public void mouseReleased(MouseEvent e) {
MyButton b = (MyButton)e.getSource();
b.setSelected(false);
b.repaint();
}
};</code=java>

Komponenten, die komplizierte Darstellungen ausgeben, sollten repaint() mit den Argumenten aufrufen, welche nur den Bereich definieren, der eine Aktualisierung erfordert. Es ist ein allgemeiner Fehler, immer die keine-Argumente Version zu benutzen, die immer die gesamte Komponente neu zeichnet, was häufig zu nicht notwendigen Malverarbeitungen führt.

===paint() gegen update()===
Warum unterscheiden wir zwischen systemausgelöstem und anwendungsausgelöstem Malen? Weil AWT jeden dieser Fälle etwas anders für heavyweight Komponenten behandelt (der lightweight Fall wird später besprochen), was leider eine Quelle großer Verwirrung ist.

Für heavyweight Komponenten geschehen diese zwei Arten des Zeichnens in zwei unterschiedlichen Wegen, abhängig davon, ob ein Malvorgang systemausgelöst oder anwendungsausgelöst ist.

====systemausgelöstes Malen====
dies ist, wie ein systemausgelöster Malvorgang stattfindet:

# Das AWT stellt fest, daß entweder ein Teil oder die ganze Komponente gemalt werden muß.
# Das AWT veranlasst den Event Dispatch Thread, paint() auf der Komponente aufzurufen.

====anwendungsausgelöstes Malen====
Ein anwendungsausgelöster Malvorgang findet wie folgt statt:

# Das Programm stellt fest, daß entweder ein Teil oder die ganze Komponente in Erwiderung auf eine interne Zustandsänderung neu gezeichnet werden muß.
# Das Programm ruft repaint() auf der Komponente auf, was einen asynchronen Antrag zum AWT registriert, daß diese Komponente neu gezeichnet werden muß.
# Das AWT veranlasst den Event Dispatch Thread, ein update() auf der Komponente aufzurufen. ANMERKUNG: Erfolgen mehrfache repaint() Aufrufe auf einer Komponente bevor der erste Antrag verarbeitet wird, können die mehrfachen Anträge zu einem einzigen Aufruf von update() zusammengefasst werden. Der Algorithmus für die Bestimmung, wann mehrfache Anträge zusammengefasst werden sollten, ist Implementierungsabhängig. Wenn mehrfache Anträge zusammengefasst werden, ist das resultierende Updaterechteck gleich der Vereinigung der Rechtecke, die in den zusammengefassten Anträgen enthalten sind.
# Wenn die Komponente nicht update() überschreibt, löscht die Default-Implementierung von update() den Hintergrund der Komponente (wenn es nicht eine lightweight Komponente ist) und ruft einfach paint() auf.

Da bei der Default-Implementierung das abschließende Resultat dasselbe ist wie bei paint(), verstehen viele Leute den Zweck einer unterschiedlichen update() Methode nicht. Während es zutreffend ist, daß die Default-Implementierung von update() die paint() aufruft, ermöglicht dieser "Updatehaken" einem Programm, den anwendungsausgelösten Malvorgang anders anzufassen, wenn es gewünscht wird. Ein Programm muß annehmen, daß ein Aufruf von paint() andeutet, daß der Bereich, der durch das Cliprechteck vom Graphics definiert wird, "beschädigt" ist und vollständig neu gezeichnet werden muß, gleichwohl ein Aufruf von update() dieses nicht andeutet, was einem Programm ermöglicht, zusätzliches Zeichnen zu tun.

Zusätzliches Zeichnen ("incremental painting") ist nützlich, wenn ein Programm die zusätzliche Darstellung über die vorhandenen Teilstücke dieser Komponente überlagern möchte. Das UpdateDemo Beispiel zeigt ein Programm, das Nutzen aus dem Verwenden von update() zieht, um zusätzliches Zeichnen zu tun:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/UpdateDemo.java UpdateDemo]

In Wahrheit braucht die Mehrheit der GUI Komponenten kein zusätzliches Zeichnen zu tun. So können die meisten Programme die update() Methode ignorieren und einfach paint() überschreiben, um die Komponente in ihrem gegenwärtigen Zustand darzustellen. Das heißt, daß die systemausgelöste und anwendungsausgelöste Darstellung im Wesentlichen für die meisten Implementierungen gleichbedeutend ist.

==Das Malen und die lightweight Komponenten ==
Von der Perspektive des Anwendungsentwicklers, ist die Mal-API im Allgemeinen dieselbe für lightweight und heavyweight Komponenten (das heißt, er überschreibt paint() und ruft repaint() auf, um Updates auszulösen). Jedoch seit AWTs lightweight Komponentenrahmen völlig im allgemeinen [[Java]] Code geschrieben wurde, sind dort einige subtile Unterschiede bezüglich der Weise, wie der Mechanismus für lightweight Komponenten implementiert wird.

===Wie lightweight Komponenten gemalt werden===
Damit eine lightweight Komponente besteht, benötigt sie einen heavyweight Vorfahr in der Containerhierarchie, um einen Platz zum Malen zu haben. Wenn diesem heavyweight Vorfahr gesagt wird, sein Fenster zu malen, muß er den Malaufruf übersetzen in Malaufrufe an alle seine lightweight Nachkommen. Dies wird durch die paint() Methode von '''java.awt.Container''' verarbeitet, welche paint() auf irgendwelchen seiner sichtbaren lightweight Kinder aufruft, die sich mit dem zu malenden Rechteck überschneiden. So ist es für alle Containerunterklassen (lighweight oder heavyweight), welche paint() überschreiben, notwendig, folgendes zu tun:

<code=java> public class MyContainer extends Container {
public void paint(Graphics g) {
// paint my contents first...
// then, make sure lightweight children paint
super.paint(g);
}
}</code=java>

Wenn der Aufruf von super.paint() fehlt, dann werden die lightweight Nachkommen des Containers nicht dargestellt (ein sehr verbreitetes Problem als JDK 1.1 die lightweight Komponenten einführte).

Es ist nützlich anzumerken, daß die Default-Implementierung von Container.update() nicht die Rekursion verwendet, um update() oder paint() auf lightweight Nachkommen aufzurufen. Das heißt, daß irgendeine heavyweight Containerunterklasse, die update() benutzt, um zusätzlichen Zeichnen zu tun, sichergehen muß, daß lightweight Nachkommen wenn nötig rekursiv neu gezeichnet werden. Glücklicherweise benötigen wenige heavyweight Container zusätzliches Zeichnen, also beeinflußt diese Frage die meisten Programme nicht.

===lightweight und systemausgelöstes Malen ===
Der lightweight Rahmencode, der das Fensterdarstellungsverhalten für lightweight Komponenten einführt (sichtbar machen, verstecken, bewegen, die Größe neu bestimmen, usw..), ist völlig in Java geschrieben. Innerhalb der Java Implementierung dieser Funktionen, muß das AWT häufig verschiedenen lightweight Komponenten ausdrücklich erklären, sich zu malen (im Wesentlichen systemausgelöstes Malen, obwohl es nicht mehr vom nativen System ausgeht). Jedoch benutzt der lightweight Rahmen '''repaint()''', um Komponenten zu erklären, sich zu malen, was einen Aufruf von update() anstatt eines Direktaufrufs von paint() ergibt, wie wir oben gesehen haben. Folglich kann systemausgelöstes Zeichnen für lightweight Komponenten zwei Wegen folgen:

* Der systemausgelöste Malantrag entsteht im nativen System (d.h. der heavyweight Vorfahr der lightweight Komponente wird zum ersten Mal sichtbar), was einen Direktaufruf von paint() ergibt.
* Der systemausgelöste Malantrag entsteht im lightweight Rahmen (d.h., die Größe der lightweight Komponente wird neu bestimmt), was einen Aufruf von update() ergibt, der in der Default-Implementierung an paint() weitergeleitet wird.

Dies bedeutet, daß es für lightweight Komponenten '''keine reale Unterscheidung zwischen update() und paint() gibt''', was weiter bedeutet, daß die zusätzliche Zeichnentechnik (incremental painting) nicht für lightweight Komponenten verwendet werden sollte.

===lightweight und Transparenz===
Da lightweight Komponenten den Bildschirmplatz eines heavyweight Vorfahrs "borgen", unterstützen sie die Eigenschaft der Transparenz. Dies funktioniert, weil lightweight Komponenten von hinten nach vorne gemalt werden und folglich, wenn eine lightweight Komponente einige oder all ihre Bits unbemalt läßt, die dahinterliegende Komponente "durchscheint". Dies ist auch der Grund, warum die Default-Implementierung von update() den Hintergrund nicht löscht, wenn die Komponente lightweight ist.

Das LightweightDemo Programmbeispiel zeigt die Transparenzeigenschaft der lightweight Komponenten:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/LightweightDemo.java LightweightDemo]

==Das "intelligente" Malen==
Während das AWT versucht, den Prozeß der Darstellung der Komponenten so leistungsfähig wie möglich zu machen, kann die paint() Implementierung einer Komponente selbst eine bedeutende Auswirkung auf die gesamte Leistung haben. Zwei Schlüsselbereiche, die diesen Prozeß beeinflussen können, sind:

* Die Clipinformationen verwenden, um den Bereich, der dargestellt wird, einzuschränken.
* Internes Wissen über das Layout verwenden, um den Bereich, welche Kinder gemalt werden, einzuschränken (nur lightweight).

Wenn deine Komponente einfach ist -- zum Beispiel, wenn es eine Drucktaste ist -- dann ist sie die Mühe nicht wert, die Darstellung zu bearbeiten, um nur den Teil zu malen, der das Cliprechteck überschneidet; es ist vorzuziehend, die gesamte Komponente zu malen und die Graphics passend einschränken zu lassen. Wenn du jedoch eine Komponente mit komplizierter Ausgabe erzeugt hast, wie eine Textkomponente, dann ist es notwendig, daß dein Code die Clipinformationen gebraucht, um den Umfang der Darstellung einzuschränken.

Weiter, wenn du einen komplizierten lightweight Container schreibst, der zahlreiche Komponenten beherbergt, wo der Container und/oder sein Layoutmanager Informationen über das Layout hat, dann ist er es wert dieses Layoutwissen zu verwenden, um intelligenter in der Bestimmung zu sein, welche der Kinder gemalt werden müssen. Die Default-Implementierung von Container.paint() schaut einfach der Reihe nach durch die Kinder und prüft die Sichtbarkeit und Überschneidung -- ein Vorgang, der mit bestimmten Layouts unnötigerweise aufwendig sein kann. Zum Beispiel, wenn ein Container die Komponenten in einem Rasterfeld 100x100 auslegt, dann könnte diese Rasterfeldinformation verwendet werden, schneller festzustellen, welche von jenen 10000 Komponenten das Cliptechteck überschneiden und wirklich gemalt werden müssen.

==AWT Malrichtlinien ==
Das AWT stellt eine einfache callback API für das Malen von Komponenten zur Verfügung. Wenn du sie verwendest, treffen die folgenden Richtlinien zu:

# Für die meisten Programme sollte aller Malcode innerhalb des Bereichs der paint() Methode der Komponente gesetzt werden.
# Programme können einen zukünftigen Aufruf von paint() auslösen, indem sie repaint() aufrufen, aber sie sollten nicht paint() direkt aufrufen.
# Bei Komponenten mit komplizierter Ausgabe, sollte repaint() mit Argumenten aufgerufen werden, die nur das Rechteck definieren, das aktualisieren muß, anstatt der keine-Argumente Version, die die gesamte Komponente veranlasst neu gezeichnet zu werden.
# Da ein Aufruf von repaint() zuerst einen Aufruf von update() ergibt, der in der Default-Implementierung an paint() weitergeleitet wird, können heavyweight Komponenten update() überschreiben, um zusätzliches Zeichnen (incremental painting) zu tun, wenn es gewünscht wird (lightweight Komponenten unterstützen nicht das zusätzliche Zeichnen).
# Erweiterungen von java.awt.Container, die paint() überschreiben, sollten immer super.paint() aufrufen, um sicherzustellen, dass die Kinder gemalt werden.
# Komponenten mit komplizierter Ausgabe sollten intelligenten Gebrauch vom Cliprechteck machen, um den Malvorgang auf den Bereich zu beschränken, der sich mit dem Clipbereich überschneidet.

=Malen in Swing=
Swing beginnt mit AWTs grundlegendem Malmodell und erweitert es, um die Leistung zu maximieren und die Erweiterbarkeit zu verbessern. Wie AWT, so unterstützt auch Swing den Malcallback und den Gebrauch von repaint(), um Updates auszulösen. Zusätzlich gibt Swing eingebaute Unterstützung für Doppelpufferung sowie Änderungen, um die zusätzliche Swing Struktur zu unterstützen (wie Ränder und der UI Delegate). Und schließlich stellt Swing die RepaintManager API für jene Programme zur Verfügung, die den Malmechanismus weiter anpassen möchten.

==Unterstützung für Doppelpufferung ==
Eine der bemerkenswertesten Eigenschaften von Swing ist, daß es die Unterstützung für Doppelpufferung direkt ins Toolkit einbaut. Das geschieht durch die Bereitstellung der "doubleBuffered" Eigenschaft in '''javax.swing.JComponent:
'''
<code=java> public boolean isDoubleBuffered()
public void setDoubleBuffered(boolean o)</code=java>

Die Doppelpufferung von Swing benutzt einen einzigen offscreen Puffer pro Containerhierarchie (normalerweise einen pro Fenster) wo die Doppelpufferung eingeschaltet worden ist. Obgleich diese Eigenschaft pro Komponente eingeschaltet werden kann, ergibt ihre Einschaltung in einem bestimmten Container den Effekt, dass alle lightweight Komponenten darunter in dem offscreen Puffer dargestellt werden, unabhängig davon wie die individuelle "doubleBuffered" Eigenschaft eingestellt ist.

Der Default-Wert dieser Eigenschaft ist bei allen Swingkomponenten auf "true" gesetzt. Aber die Einstellung, die wirklich zählt, ist in JRootPane, weil diese Einstellung effektiv Doppelpufferung für alles darunter einschaltet. In den meisten Fällen brauchen Swingprogramme nichts zu tun in Bezug auf Doppelpufferung, ausgenommen, zu entscheiden, ob sie ein- oder ausgeschaltet sein sollte (und für eine flackerfreie GUI wirst du wünschen, dass sie eingeschaltet ist!). Swing stellt sicher, daß die passende Art des Graphics Objektes (offscreen Bild Graphics für Doppelpufferung, sonst die original Graphics) der Komponente übergeben wird, so braucht die Komponente lediglich mit ihm zu zeichnen. Dieser Mechanismus wird später in diesem Artikel ausführlicher erklärt (im Abschnitt über die Malverarbeitung).

==Zusätzliche Maleigenschaften ==
Swing stellt einige zusätzliche Eigenschaften von JComponent vor, um die Leistungsfähigkeit der internen Malalgorithmen zu verbessern. Diese Eigenschaften wurden eingeführt, um sich mit den folgenden zwei Fragen zu beschäftigen, die das Zeichnen von lightweight Komponenten zu einem kostspieligen Vorgang machen können:

* '''Transparenz''': Wenn eine lightweight Komponente gemalt wird, ist es möglich, daß die Komponente nicht alle ihre Bits malt, wenn sie teilweise oder ganz transparent ist; das heißt, daß, wann immer sie neu gezeichnet wird, das was dahinter liegt zuerst neu gezeichnet werden muss. Das erfordert vom System, die Containerhierarchie hinaufzugehen um den ersten zugrundeliegenden heavyweight Vorfahr zu finden, von dem der hinten-nach-vorne Malvorgang ausgehen soll.
* '''Überlappende Komponenten''': Wenn eine lightweight Komponente gemalt wird, ist es möglich, daß irgendeine andere lightweight Komponente sie teilweise verdeckt; das heißt, daß, wann immer die ursprüngliche lightweight Komponente gemalt wird, alle möglichen Komponenten, die die ursprüngliche Komponente überdecken (wo das Cliprechteck sich mit dem überlappenden Bereich schneidet), auch teilweise neu gezeichnet werden müssen. Dies erfordert vom System, bei jedem Malvorgang viel von der Containerhierarchie zu durchqueren und auf überlappende Komponenten zu überprüfen.

===Die Opazität===
Um im Fall von undurchlässigen Komponenten die Leistung zu verbessern, fügt Swing eine "opaque" Lese-Schreibeigenschaft zu javax.swing.JComponent hinzu:

<code=java> public boolean isOpaque()
public void setOpaque(boolean o)</code=java>

Die Einstellungen sind:

*true: Die Komponente ist damit einverstanden, alle ihre Bits zu malen, die innerhalb ihrer rechteckigen Grenzen enthalten sind.
*false: Der Komponente gibt keine Garantien über das Malen aller Bits innerhalb ihrer rechteckigen Grenzen.

Die "opaque" Eigenschaft läßt das Malsystem von Swing ermitteln, ob ein repaint Antrag auf einer bestimmten Komponente zusätzliche repaint Anträge der dahinter liegenden Vorfahren erfordert oder nicht. Der Default-Wert der "opaque" Eigenschaft für jede standard Swingkomponente wird durch das gegenwärtige Look and Feel UI Objekt eingestellt. Der Wert ist für die meisten Komponenten "true".

Einer der allgemeinsten Fehler, die Komponentenimplementierungen machen, ist, daß sie die "opaque" Eigenschaft auf "true" belassen, und dennoch den Bereich nicht vollständig darstellen, der durch ihre Grenzen definiert ist, was gelegentliche Unreinheiten in den nicht dargestellten Bereichen ergibt. Wenn eine Komponente entworfen wird, sollte sorgfältig überlegt werden, wie die "opaque" Eigenschaft zu behandeln ist, sowohl um sicherzustellen, daß Transparenz klug benutzt wird, da sie mehr Darstellungszeit kostet, und daß die Übereinkunft mit dem Malsystem eingehalten wird.

Die Bedeutung der "opaque" Eigenschaft wird häufig mißverstanden. Manchmal wird sie verstanden als "den Hintergrund der Komponente transparent machen". Jedoch ist dies nicht die strenge Deutung der Opazität in Swing. Einige Komponenten, wie eine Drucktaste, können die "opaque" Eigenschaft auf false setzen, um der Komponente eine nicht-rechteckige Form zu geben oder Raum um die Komponente herum zu behalten für vorübergehende Sichtbarmachungen, wie eine Fokusanzeige. In diesen Fällen ist die Komponente nicht opaque, aber der Hauptteil seines Hintergrundes wird dennoch ganz ausgefüllt!

Wie vorher definiert, ist die "opaque" Eigenschaft hauptsächlich ein Vertrag mit dem Repaintsystem. Wenn eine Komponente auch die "opaque" Eigenschaft benutzt, um zu definieren, wie Transparenz an den Sichtbarmachungen einer Komponente angewendet wird, dann sollte dieser Gebrauch von der Eigenschaft dokumentiert werden. (es kann für einige Komponenten vorzuziehen sein, zusätzliche Eigenschaften zu definieren, um die Sichtaspekte davon zu steuern, wie Transparenz angewendet wird. Z.B. hat javax.swing.AbstractButton die ContentAreaFilled Eigenschaft zu diesem Zweck.)

Eine andere Frage, die eine Anmerkung wert ist, ist wie sich Opazität auf die Randeigenschaft einer Swingkomponente bezieht. Der Bereich, der durch ein Randobjekt auf einer Komponente dargestellt wird, wird noch als ein Teil der Geometrie dieser Komponente betrachtet. Das heißt, daß, wenn eine Komponente "opaque" ist, sie immer noch für das Füllen des Bereichs verantwortlich ist, der durch den Rand besetzt wird. (der Rand überlagert dann einfach seine Darstellung über die undurchlässige Komponente).

Wenn eine dahinter liegende Komponente durch den Randbereich einer Komponente durchscheinen soll -- das heißt, wenn der Rand Transparenz unterstützt indem isBorderOpaque() "false" zurückgibt (z.B. EmptyBorder oder LineBorder mit roundedCorners) -- dann, muß die Komponente sich selbst auch als nicht opaque definieren und sicherstellen dass sie den Randbereich nicht übermalt.

Siehe auch: http://forum.java.sun.com/thread.jspa?messageID=10329261&start=1

==="optimiert" zeichnen===
Die Frage des Zeichnens von überlappenden Komponenten ist heikler. Selbst wenn keiner der direkten Geschwister einer Komponente diese überdeckt, ist es immer möglich, daß ein Nichtvorfahr Verwandter (wie ein "Vetter" oder "Tante") sie verdecken könnte. In solch einem Fall könnte das repaint einer einzelnen Komponente innerhalb einer komplizierten Hierarchie eine Menge Treewalking erfordern, um 'korrektes' Zeichnen sicherzustellen. Um unnötiges Durchqueren zu verringern, fügt Swing die read-only Eigenschaft "isOptimizedDrawingEnabled" zu javax.swing.JComponent hinzu:

<code=java> public boolean isOptimizedDrawingEnabled()</code=java>

die Einstellungen sind:

* true: Die Komponente zeigt an, daß keine seiner direkten Kinder sich überlappen.
* false: Die Komponente gibt keine Garantie, ob seine direkten Kinder sich überlappen oder nicht.

Indem es die Eigenschaft "isOptimizedDrawingEnabled" überprüft, kann Swing schnell seine Suche nach überlappenden Komponenten zur repaint Zeit eingrenzen.

Da "isOptimizedDrawingEnabled" eine read-only Eigenschaft ist, ist also der einzige Weg, wie Komponenten den Default-Wert ändern können, die Klasse zu erweitern und diese Methode zu überschreiben, um den gewünschten Wert zurückzugeben. Alle standard Swingkomponenten geben "true" für diese Eigenschaft zurück, außer JLayeredPane, JDesktopPane und JViewPort. Wenn wir also z.B. ein JPanel mit einem Layout haben, das überlappende Komponenten zulässt (wie "OverlayLayout"), dann ist es gewöhnlich notwendig, JPanel zu erweitern und isOptimizedDrawingEnabled() zu überschreiben, um "false" zurückzugeben.

==Die Malmethoden ==
Die Richtlinien, die auf AWTs lightweight Komponenten zutreffen, treffen auch auf Swingkomponenten zu -- zum Beispiel wird paint() aufgerufen, wenn es Zeit ist darzustellen -- außer daß Swing den paint() Aufruf in drei verschiedene Methoden unterteilt, die in folgender Reihenfolge aufgerufen werden:

<code=java> protected void paintComponent(Graphics g)
protected void paintBorder(Graphics g)
protected void paintChildren(Graphics g)</code=java>

Swingprogramme sollten '''paintComponent()''' anstelle von paint() überschreiben. Obgleich die API es erlaubt, gibt es im Allgemeinen keinen Grund paintBorder() oder paintChildren() zu überschreiben (und wenn du es tust, sei dir sicher was du tust!). Dies macht es den Programmen einfacher, nur den Teil des Zeichnens zu überschreiben, den sie erweitern müssen. Z.B. löst dies das AWT Problem, das vorher erwähnt wurde, wo die Unterlassung, super.paint() aufzurufen alle lightweight Kinder am Erscheinen hinderte.

Das SwingPaintDemo Programmbeispiel zeigt den einfachen Gebrauch der paintComponent() callback Methode von Swing:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/SwingPaintDemo.java SwingPaintDemo]

===Das Malen und der UI Delegate ===
Die meisten standard Swingkomponenten haben ihren Look and Feel implementiert durch getrennte look-and-feel Objekte (genannt "UI Beauftragte"), für die steckbare Look and Feel Eigenschaft von Swing. Das heißt, daß das meiste oder das ganze Zeichnen der standard Komponenten dem UI Delegate übergeben wird und dies geschieht folgendermaßen:

# paint() ruft paintComponent() auf.
# Wenn die "ui" Eigenschaft nicht "null" ist, ruft paintComponent() ui.update() auf.
# Wenn die "opaque" Eigenschaft der Komponente "true" ist, füllt ui.update() den Hintergrund der Komponente mit der Hintergrundfarbe und ruft ui.paint() auf.
# ui.paint() stellt den Inhalt der Komponente dar.

Das heißt, daß Unterklassen von Swingkomponenten, die einen UI Delegate haben (im Gegensatz zu direkten Unterklassen von JComponent), super.paintComponent() innerhalb ihrer paintComponent Überschreibung aufrufen sollten:

<code=java> public class MyPanel extends JPanel {
protected void paintComponent(Graphics g) {
// Let UI delegate paint first
// (including background filling, if I'm opaque)
super.paintComponent(g);
// paint my contents next....
}
}</code=java>

Wenn aus irgendeinem Grund die Erweiterung der Komponente nicht zulassen möchte, daß der UI Delegate malt (wenn sie zum Beispiel die sichtbaren Elemente der Komponente vollständig ersetzt), kann sie den Aufruf von super.paintComponent() weglassen, aber sie ist dann für das Ausfüllen ihres eigenen Hintergrundes verantwortlich, wenn die "opaque" Eigenschaft "true" ist, wie im Abschnitt über die "opaque" Eigenschaft besprochen wurde.

==Malverarbeitung ==
Swing verarbeitet "repaint" Anträge in einer etwas anderen Weise als AWT, obgleich das Resultat für den Anwendungsprogrammierer im Wesentlichen dasselbe ist -- paint() wird aufgerufen. Swing tut dies, um seine RepaintManager API zu unterstützen (wird später besprochen), sowie zur Verbesserung der Malleistung. In Swing kann das Malen zwei Wegen folgen, wie unten beschrieben:

(a) Der Malantrag entsteht im ersten heavyweight Vorfahr (normalerweise JFrame, JDialog, JWindow oder JApplet):

# der "event dispatching thread" ruft paint() für diesen Vorfahr auf,
# die Default-Implementierung von Container.paint() ruft rekursiv paint() auf allen lightweight Nachkommen auf,
# wenn die erste Swingkomponente erreicht wird, macht die Default-Implementierung von '''JComponent.paint()''' folgendes:
## wenn die "doubleBuffered" Eigenschaft der Komponente "true" ist und Doppelpufferung ist im RepaintManager der Komponente eingeschaltet, wandelt sie das Graphics Objekt um zu einem passenden offscreen Graphics.
## ruft paintComponent() auf (und übergibt offscreen Graphics, wenn "doubleBuffered")
## ruft paintBorder() auf (und übergibt offscreen Graphics, wenn "doubleBuffered")
## ruft paintChildren() auf (und übergibt offscreen Graphics, wenn "doubleBuffered") welche die Eigenschaften "clip", "opaque" und "optimizedDrawingEnabled" verwendet, um genau festzustellen, für welche Nachkommen, "paint()" rekursiv aufzurufen ist.
## wenn die "doubleBuffered" Eigenschaft der Komponente "true" ist und Doppelpufferung ist im RepaintManager der Komponente eingeschaltet, kopiert sie das offscreen Bild auf die Komponente unter Benutzung des ursprünglichen onscreen Graphics Objektes.

::ANMERKUNG: die JComponent.paint() Schritte #1 und #5 werden in den rekursiven Aufrufen von paint() übersprungen (in paintChildren(), beschrieben in Schritt #4) weil alle lightweight Komponenten innerhalb einer Swingfensterhierarchie dasselbe offscreen Bild für Doppelpufferung teilen.

(b) Der Malantrag entsteht durch einen Aufruf von repaint() auf einer Erweiterung von javax.swing.JComponent:
# JComponent.repaint() registriert einen asynchronen repaint Antrag beim RepaintManager der Komponente, der invokeLater() benutzt, um einen Runnable entstehen zu lassen, der den Antrag später auf dem "event dispatching thread" verarbeitet.
# der Runnable wird auf dem "event dispatching thread" ausgeführt und er veranlasst den RepaintManager der Komponente, '''paintImmediately()''' auf der Komponente aufzurufen, die folgendes tut:
## verwendet das Cliprechteck und die Eigenschaften "opaque" und "optimizedDrawingEnabled", um die 'root' Komponente festzustellen, von der aus der Malvorgang anfangen muß (um sich um Transparenz und möglicherweise überlappende Komponenten kümmern zu können).
## wenn die "doubleBuffered" Eigenschaft der 'root' Komponente "true" ist und Doppelpufferung ist im RepaintManager vom 'root' eingeschaltet, wandelt sie das Graphics Objekt um zu einem passenden offscreen Graphics.
## ruft paint() auf der 'root' Komponente auf (was die JComponent.paint() Schritte #2-4 oben unter (a) durchführt), und verursacht so, daß alles unter dem 'root' gemalt wird, was sich mit dem Cliprechteck überschneidet.
## wenn die "doubleBuffered" Eigenschaft der 'root' Komponente "true" ist und Doppelpufferung ist im RepaintManager der 'root' Komponente eingeschaltet, kopiert sie das offscreen Bild auf die Komponente unter Benutzung des ursprünglichen onscreen Graphics Objektes.

::ANMERKUNG: wenn mehrfache Aufrufe von repaint() auf einer Komponente oder irgendwelchen seiner Swingvorfahren auftreten, bevor der repaint Antrag verarbeitet wird, können jene mehrfachen Anträge in einen einzigen Callback von paintImmediately() auf der obersten Swingkomponente zusammengefasst werden, auf der repaint() aufgerufen wurde. Z.B. wenn ein JTabbedPane eine JTable enthält und beide Aufrufe von repaint() absenden, bevor irgendwelche anstehenden Anträge dieser Hierarchie verarbeitet werden, ist das Resultat ein einziger Aufruf von paintImmediately() auf dem JTabbedPane, was veranlasst, daß paint() auf beiden Komponenten durchgeführt wird.

Das heißt, daß update() für SwingKomponenten nie aufgerufen wird.

Obgleich repaint() einen Aufruf von paintImmediately() ergibt, gilt es nicht als "Malcallback" , und Malcode sollte nicht innerhalb einer paintImmediately() gesetzt werden. Tatsächlich gibt es im Allgemeinen überhaupt keinen Grund, paintImmediately() zu überschreiben.

===Synchrones Zeichnen===
Wie im vorhergehenden Abschnitt beschrieben, dient paintImmediately() als Ausgangspunkt um einer einzelnen Swingkomponente zu sagen, sich zu malen und zu überprüfen, ob alles erforderliche Zeichnen passend geschieht. Diese Methode kann auch für synchrone Malanträge verwendet werden, wie sein Name andeutet, was manchmal bei Komponenten erfordert ist, die sicherstellen müssen, daß ihr Aussehen in Echtzeit mit ihrem internen Zustand 'Schritt hält' (z.B. gilt dies für das JScrollPane während eines Rollvorgangs).

Programme sollten diese Methode nicht direkt aufrufen, es sei denn, es gibt eine tatsächliche Notwendigkeit zum Zeichnen in Echtzeit. Das ist so, '''weil durch das asynchrone repaint() mehrfache überlappende Anträge leistungssteigernd zusammengefasst werden''', während das bei Direktaufrufen von paintImmediately() nicht geschieht. Zusätzlich ist die Richtlinie für das Aufrufen dieser Methode, daß sie auf dem "event dispatching thread" aufgerufen werden muß; es ist keine API, die für den "multi-threading" Ihres Malcodes bestimmt ist! Für mehr Einzelheiten über das "single-threaded" Modell von Swing, siehe den archivierten Artikel "Threads and Swing" :

[http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html Threads and Swing]

==Der RepaintManager ==
Der Zweck der Swingklasse "RepaintManager" ist, die Leistungsfähigkeit der repaint Verarbeitung auf einer Swing Containerhierarchie zu maximieren, und auch zur Implementierung des "revalidation" Mechanismus von Swing (letzteres wird das Thema für einen weiteren Artikel sein, siehe auch: [http://www.java-forum.org/de/viewtopic.php?p=431845#431845 Validierung mit Swing]). Sie implementiert den repaint Mechanismus, indem sie alle repaint Anträge von Swing Komponenten abfängt (also werden sie nicht mehr durch das AWT verarbeitet) und ihren eigenen Zustand beibehält in Bezug auf das, was aktualisiert werden muss (bekannt als "dirty regions", also "verschmutzte Bereiche"). Schließlich benutzt sie invokeLater(), um die anstehenden Anträge auf dem "event dispatching thread" zu verarbeiten, wie im Abschnitt "Malverarbeitung" beschrieben (Option b). [Der RepaintManager wird eine Serie von Malanträgen möglichst zusammenfassen, wenn (und nur wenn) der "Anführer" der Serie mit invokeLater verschickt wurde, aber noch nicht auf dem EDT verarbeitet wurde.]

Für die meisten Programme kann der RepaintManager als Teil des internen Systems von Swing angesehen werden und praktisch ignoriert werden. Jedoch liefert seine API den Programmen die Möglichkeit einer feineren Steuerung von bestimmten Aspekten des Zeichnens.

===Der "gegenwärtige" RepaintManager ===
Der RepaintManager ist entworfen, um dynamisch ausgewechselt zu werden, obgleich es durch die Default-Implementierung eine einzige Instanz gibt. Die folgenden statischen Methoden lassen Programme auf den "gegenwärtigen" RepaintManager zugreifen und ihn ersetzen:

<code=java> public static RepaintManager currentManager(Component c)
public static RepaintManager currentManager(JComponent c)
public static void setCurrentManager(RepaintManager aRepaintManager)</code=java>

===Den "gegenwärtigen" RepaintManager ersetzen===
Ein Programm würde den RepaintManager global erweitern und ersetzen, indem es folgendes tut:

<code=java> RepaintManager.setCurrentManager(new MyRepaintManager());</code=java>

Du kannst dir RepaintManagerDemo ansehen als ein einfaches lauffähiges Beispiel für die Installation von einem RepaintManager, der Informationen ausdruckt über das, was neu gezeichnet wird:

[http://java.sun.com/products/jfc/tsc/articles/painting/src/RepaintManagerDemo.java RepaintManagerDemo]

Ein interessanterer Grund für das Erweitern und das Ersetzen des RepaintManagers wäre die Art und Weise zu verändern, wie repaint Anträge verarbeitet werden. Zur Zeit ist der interne Zustand, der durch die Default-Implementierung benutzt wird, um schmutzige Regionen aufzuspüren, "package privat" und folglich nicht durch Unterklassen zugänglich. Jedoch können Programme ihre eigenen Mechanismen für das Aufspüren von schmutzigen Regionen und für das Zusammenfassen von repaint Anträgen einführen, indem sie die folgenden Methoden überschreiben:

<code=java> public synchronized void addDirtyRegion(JComponent c, int x, int y, int w, int h)
public Rectangle getDirtyRegion(JComponent aComponent)
public void markCompletelyDirty(JComponent aComponent)
public void markCompletelyClean(JComponent aComponent) {</code=java>

Die addDirtyRegion() Methode ist die, die aufgerufen wird, wenn repaint() auf einer Swingkomponente aufgerufen wird, und kann folglich angespannt werden, um alle repaint Anträge abzufangen. Wenn ein Programm diese Methode überschreibt (und nicht super.addDirtyRegion() aufruft), dann wird es dafür verantwortlich, invokeLater() zu benutzen, um einen Runnable auf die "EventQueue" zu setzen, der paintImmediately() auf einer passenden Komponente aufruft (Übersetzung: nicht für Leute mit schwachem Herzen).

===Globale Steuerung der Doppelpufferung===
Der RepaintManager stellt eine API zur Verfügung, um die Doppelpufferung global zu ermöglichenden und zu sperren:

<code=java> public void setDoubleBufferingEnabled(boolean aFlag)
public boolean isDoubleBufferingEnabled()</code=java>

Während der Verarbeitung eines Malvorgangs wird diese Eigenschaft innerhalb JComponent überprüft, um festzustellen, ob man einen offscreen Puffer für die Darstellung verwendet. Diese Eigenschaft hat den Default-Wert "true", aber die Programme, die Doppelpufferung für alle Swingkomponenten global sperren möchten, können folgendes tun:

<code=java> RepaintManager.currentManager(mycomponent).setDoubleBufferingEnabled(false);</code=java>

Anmerkung: da die Default-Implementierung von Swing einen einzigen RepaintManager instanziert, ist das "mycomponent" Argument irrelevant.

==Swing Malrichtlinien ==
Swingprogramme sollten diese Richtlinien verstehen, wenn Malcode geschrieben wird:

# Für Swingkomponenten wird immer ''paint()'' aufgerufen als Ergebnis sowohl von systemausgelösten als auch von anwendungsausgelösten Malanträgen; ''update()'' wird nie auf Swingkomponenten aufgerufen.
# Programme können einen zukünftigen Aufruf von ''paint()'' auslösen, indem sie ''repaint()'' aufrufen, aber sie sollten ''paint()'' nicht direkt aufrufen.
# Auf Komponenten mit komplizierter Ausgabe, sollte ''repaint()'' mit Argumenten aufgerufen werden, die nur das Rechteck, das aktualisieren muß, definieren, und nicht die keine-Argumente-Version, die die gesamte Komponente veranlasst, neu gezeichnet zu werden.
# Die Swing Implementierung von paint() unterteilt den Aufruf in 3 verschiedene callback Methoden:
#* ''paintComponent()'': Erweiterungen von Swingkomponenten, die ihren eigenen Malcode einführen möchten, sollten diesen Code innerhalb des Bereichs der Methode paintComponent() setzen (nicht innerhalb von paint()).
#* ''paintBorder()''
#* ''paintChildren()''
# Swing stellt zwei Eigenschaften vor, um die Malleistung zu maximieren:
#*''opaque'': malt die Komponente alle ihre Bits oder nicht?
#*''optimizedDrawingEnabled'': können irgendwelche der Kinder dieser Komponente sich überschneiden?
# Wenn die ''opaque'' Eigenschaft einer Swingkomponente auf ''true'' gesetzt wird, dann erklärt sie sich damit einverstanden, alle Bits zu malen, die innerhalb ihrer Grenzen enthalten sind (dies schließt das Löschen ihres eigenen Hintergrundes innerhalb von ''paintComponent()'' ein), andernfalls können Bilschirmunreinheiten auftreten.
# Das Setzen entweder von ''opaque'' oder ''optimizedDrawingEnabled'' auf ''false'' für eine Komponente verursacht mehr Verarbeitung bei jedem Malvorgang, folglich empfehlen wir vernünftigen Gebrauch von Transparenz und überlappenden Komponenten zu machen.
# Erweiterungen von Swingkomponenten, die ''UI Delegates'' haben (einschließlich ''JPanel''), sollten gewöhnlich ''super.paintComponent()'' innerhalb ihrer eigenen ''paintComponent()'' Implementierung aufrufen. Da der ''UI Delegate'' die Verantwortung für das Löschen des Hintergrundes auf undurchlässigen Komponenten hat, kümmert er sich um #6.
# Swing unterstützt eingebaute Doppelpufferung über die ''doubleBuffered'' Eigenschaft von ''JComponent'', und ihr Default-Wert ist ''true'' für alle Swingkomponenten, gleichwohl das Setzen auf ''true'' auf einem Swingcontainer den allgemeinen Effekt hat, sie für alle lightweight Nachkommen dieses Containers einzuschalten, unabhängig von ihren einzelnen Einstellungen.
# Es wird ausdrücklich empfohlen, daß Doppelpufferung für alle Swingkomponenten ermöglicht wird.
# Komponenten, die komplizierte Ausgaben darstellen, sollten intelligenten Gebrauch vom Cliprechteck machen, um die Malvorgänge auf diejenigen zu beschränken, die sich mit dem Clipbereich schneiden.

=Zusammenfassung =
Beide, AWT und Swing, liefern APIs, um es den Programmen einfach zu machen, ihren Inhalt korrekt am Bildschirm darzustellen. Obgleich wir empfehlen, daß Entwickler für die meisten GUI Bedürfnisse Gebrauch von Swing machen, ist es nützlich, AWTs Malmechanismus zu verstehen, weil derjenige von Swing darauf aufbaut.

Um die beste Leistung von diesen APIs zu erhalten, müssen Anwendungsprogramme die Verantwortung dafür übernehmen, die in diesem Dokument umrissenen Richtlinien zu befolgen.

[[Kategorie:Java]]
[[Kategorie:Tutorials (Java)]]
[[Kategorie:Swing]]

Benutzer Diskussion:AndreUhres

2012-12-30T06:34:15Z

AndreUhres: Korrektur bezüglich ActionListener

Danke Marco13 für die Korrektur bezüglich ActionListener. Ich frage mich jetzt, wieso es vorher funktionieren konnte??

Datei:Taschenrechner.jpg

2012-10-18T01:52:56Z

AndreUhres: lud eine neue Version von „Datei:Taschenrechner.jpg“ hoch

Command (Design Pattern)

2012-10-15T14:17:45Z

AndreUhres:

Das Command Design Pattern kapselt eine Anfrage als ein Objekt, so dass wir unsere Kunden mit unterschiedlichen Anfragen parametrieren können, Anfragen in einer Warteschlange oder einem Journal ablegen können, und aufhebbare Operationen unterstützen können.

Das Command Design Pattern entkoppelt ein Objekt das eine Anfrage macht, von demjenigen der weiß, wie diese Anfrage auszuführen ist. Im Mittelpunkt dieser Entkopplung steht ein Kommando-Objekt, das einen Empfänger und eine Aktion (oder eine Reihe von Aktionen) kapselt. Ein Aufrufer (invoker) richtet eine Anfrage an ein Kommando-Objekt durch den Aufruf seiner execute()-Methode, die wiederum die Aktionen des Empfängers (receiver) aufruft. Aufrufer können mit unterschiedlichen Befehlen konfiguriert werden, auch dynamisch zur Laufzeit.

Die Befehle können auch eine "undo"-Funktion unterstützen (rückgängig machen), indem sie eine undo()-Methode umsetzen, die das Empfänger-Objekt wieder in seinen vorherigen Zustand bringt, d.h. in den Zustand vor dem letzten Aufruf der Methode execute().

Ein Makro-Kommando ist eine einfache Erweiterung eines Kommandos, so dass er mehrere Befehle aufrufen kann. Ebenso kann ein Makro-Kommando die undo-Funktion leicht unterstützen.

Kommandos können auch für die Umsetzung von Transaktions- und Logging-Systemen verwendet werden.

Stellen wir uns zum Beispiel einen Empfänger "Prozessor" vor, der arithmetische Operationen durchführen kann:

<code=java>
package command;

public class Prozessor
{

private double resultat;
private String operator;
private double operand;

/**
* Ein Prozessor für arithmetische Operationen
*/
public Prozessor(){
}

/**
* Berechnung von arithmetischen Operationen, wobei das Resultat kumuliert wird.
* Das aktuelle Resultat wird auf dem Bildschirm angezeigt
* und kann mit Hilfe der Methode getResultat() abgefragt werden.
* @param operator Addition=+, Substraktion=-, Multiplikation=* Division=/
* @param operand eine Zahl vom Typ "double"
*/
public void berechnung(final String operator, final double operand)
{
this.operator = operator;
this.operand = operand;
switch (operator)
{
case "+":
resultat += operand;
break;
case "-":
resultat -= operand;
break;
case "*":
resultat *= operand;
break;
case "/":
resultat /= operand;
break;
}
System.out.println(this);
}

public double getResultat()
{
return resultat;
}

@Override
public String toString()
{
return operator + " " + operand + " = " + resultat;
}
}
</code=java>

Die Schnittstelle "Command" ermöglicht es, eine Aktion auf dem Prozessor auszuführen und rückgängig zu machen. Sie ist sehr einfach:

<code=java>
package command;

//Die Schnittstelle Command wird von den Klassen Berechnung, Reset und MacroCommand umgesetzt.
public interface Command
{

public void execute();

public void undo();
}
</code=java>

Die Klasse "Berechnung" ist ein konkreter Befehl, der eine arithmetische Operation berechnet:

<code=java>
package command;

//eine konkreter Befehl, der eine arithmetische Operation berechnet
public class Berechnung implements Command
{

private Prozessor prozessor;
private String operator;
private double operand;

public Berechnung(final Prozessor prozessor, final String operator, final double operand)
{
this.prozessor = prozessor;
this.operator = operator;
this.operand = operand;
}

@Override
public void execute()
{
prozessor.berechnung(operator, operand);
}

@Override
public void undo()
{
switch (operator)
{
case "+":
prozessor.berechnung("-", operand);
break;
case "-":
prozessor.berechnung("+", operand);
break;
case "*":
prozessor.berechnung("/", operand);
break;
case "/":
prozessor.berechnung("*", operand);
break;
}
}

@Override
public String toString()
{
return operator + "" + operand;
}
}
</code=java>

Die Klasse "Reset" ist auch ein konkreter Befehl, der den Prozessor zurücksetzt:

<code=java>
package command;

//ein konkreter Befehl, der den Prozessor zurücksetzt:
public class Reset implements Command
{

private Prozessor prozessor;
private double resultat;

public Reset(final Prozessor prozessor)
{
this.prozessor = prozessor;
}

@Override
public void execute()
{
resultat = prozessor.getResultat();
prozessor.berechnung("-", resultat);
}

@Override
public void undo()
{
prozessor.berechnung("+", resultat);
}

@Override
public String toString()
{
return "Reset{" + resultat + '}';
}
}
</code=java>

Die Klasse "MacroCommand" kann eine Reihe von Befehlen ausführen, die als Parameter übergeben werden:

<code=java>
package command;

import java.util.Arrays;

public class MacroCommand implements Command
{

private final Command[] commands;

/**
* Ein MacroCommand kann eine Reihe von Befehlen ausführen, die als Parameter übergeben werden.
*
* @param commands eine Reihe von Befehlen
*/
public MacroCommand(final Command[] commands)
{
this.commands = commands;
}

@Override
public void execute()
{
for (int i = 0; i < commands.length; i++)
{
commands[i].execute();
}
}

@Override
public void undo()
{
for (int i = commands.length - 1; i >= 0; i--)
{
commands[i].undo();
}
}

@Override
public String toString()
{
return Arrays.toString(commands);
}
}
</code=java>

Die Klasse "Taschenrechner" ist ein Aufrufer von Befehlen; sie weiß, wie man Befehle ausführen und rückgängig machen kann:

<code=java>
package command;

import java.util.ArrayList;
import java.util.List;

public class Taschenrechner
{

private List<Command> undoable;
private int undoLevel;

/**
* Ein Taschenrechner der Befehle ausführen und rückgängig machen kann.
*/
public Taschenrechner()
{
undoable = new ArrayList<>(10);
undoLevel = 0;
}

/**
* Den Befehl ausführen, der als Parameter übergeben wird.
*
* @param command
*/
public void execute(final Command command)
{
System.out.print("Berechnung: ");
command.execute();
addUndoable(command);
}

/**
* Die als Parameter übergebene Anzahl von Befehlen rückgängig machen.
*
* @param number
*/
public void undo(final int number)
{
System.out.println("undo(" + number + "):");
for (int i = 0; i < number; i++)
{
if (undoLevel > 0)
{
Command commande = undoable.get(--undoLevel);
commande.undo();
}
}
}

/**
* Die als Parameter übergebene Anzahl von Befehlen wieder ausführen.
*
* @param number
*/
public void redo(final int number)
{
System.out.println("redo(" + number + "):");
for (int i = 0; i < number; i++)
{
if (undoLevel < undoable.size())
{
Command commande = undoable.get(undoLevel++);
commande.execute();
}
}
}

//private Servicemethode:
private void addUndoable(final Command command)
{
//die "undoable"-Liste dem aktuellen undoLevel anpassen:
int count = undoable.size() - undoLevel;
for (int i = 0; i < count; i++)
{
undoable.remove(undoable.size() - 1);
}
//den neuen Befehl hinzufügen:
undoable.add(command);
undoLevel = undoable.size();
}
}
</code=java>

Und schließlich ist hier die Starter-Klasse, zum Testen unseres kleinen Taschenrechners, der dynamisch mit verschiedenen Befehlen konfigurierbar ist:

<code=java>
package command;

public class Demo
{

public static void main(final String[] args)
{
Prozessor prozessor = new Prozessor();
Taschenrechner taschenrechner = new Taschenrechner();

taschenrechner.execute(new Berechnung(prozessor, "-", 4));
taschenrechner.execute(new Berechnung(prozessor, "*", 3));
taschenrechner.execute(new Berechnung(prozessor, "+", 14));
double resultat = prozessor.getResultat();

Command[] pi = new Command[]
{
new Reset(prozessor),
new Berechnung(prozessor, "+", 103993),
new Berechnung(prozessor, "/", 33102),
};

taschenrechner.execute(new MacroCommand(pi));
taschenrechner.execute(new Berechnung(prozessor, "+", resultat));

taschenrechner.undo(2);
taschenrechner.redo(1);

taschenrechner.execute(new Reset(prozessor));
}
}
</code=java>

Der Taschenrechner gibt dies auf der Konsole aus:

[[Datei:Taschenrechner.jpg]]

[[Kategorie:Java]]
[[Kategorie:Design Pattern]]
[[Kategorie:Design Patterns]]
[[Kategorie:Gang of Four Pattern]]

Command (Design Pattern)

2012-10-15T13:50:12Z

AndreUhres:

Das Command Design Pattern kapselt eine Anfrage als ein Objekt, so dass wir unsere Kunden mit unterschiedlichen Anfragen parametrieren können, Anfragen in einer Warteschlange oder einem Journal ablegen können, und aufhebbare Operationen unterstützen können.

Das Command Design Pattern entkoppelt ein Objekt das eine Anfrage macht, von demjenigen der weiß, wie diese Anfrage auszuführen ist. Im Mittelpunkt dieser Entkopplung steht ein Kommando-Objekt, das einen Empfänger und eine Aktion (oder eine Reihe von Aktionen) kapselt. Ein Aufrufer (invoker) richtet eine Anfrage an ein Kommando-Objekt durch den Aufruf seiner execute()-Methode, die wiederum die Aktionen des Empfängers (receiver) aufruft. Aufrufer können mit unterschiedlichen Befehlen konfiguriert werden, auch dynamisch zur Laufzeit.

Die Befehle können auch eine "undo"-Funktion unterstützen (rückgängig machen), indem sie eine undo()-Methode umsetzen, die das Empfänger-Objekt wieder in seinen vorherigen Zustand bringt, d.h. in den Zustand vor dem letzten Aufruf der Methode execute().

Ein Makro-Kommando ist eine einfache Erweiterung eines Kommandos, so dass er mehrere Befehle aufrufen kann. Ebenso kann ein Makro-Kommando die undo-Funktion leicht unterstützen.

Kommandos können auch für die Umsetzung von Transaktions- und Logging-Systemen verwendet werden.

Stellen wir uns zum Beispiel einen Empfänger "Prozessor" vor, der arithmetische Operationen durchführen kann:

<code=java>
package command;

public class Prozessor
{

private double resultat;
private String operator;
private double operand;

/**
* Ein Prozessor für arithmetische Operationen
*/
public Prozessor(){
}

/**
* Berechnung von arithmetischen Operationen, wobei das Resultat kumuliert wird.
* Das aktuelle Resultat wir auf dem Bildschirm angezeigt
* und kann mit der Methode getResultat() abgefragt werden.
* @param operator Addition=+, Substraktion=-, Multiplikation=* Division=/
* @param operand eine Zahl vom Typ "double"
*/
public void berechnung(final String operator, final double operand)
{
this.operator = operator;
this.operand = operand;
switch (operator)
{
case "+":
resultat += operand;
break;
case "-":
resultat -= operand;
break;
case "*":
resultat *= operand;
break;
case "/":
resultat /= operand;
break;
}
System.out.println(this);
}

public double getResultat()
{
return resultat;
}

@Override
public String toString()
{
return operator + " " + operand + " = " + resultat;
}
}
</code=java>

Die Schnittstelle "Command" ermöglicht es eine Aktion auf dem Prozessor auszuführen und rückgängig zu machen. Sie ist sehr einfach:

<code=java>
package command;

//Die Schnittstelle Command wird von den Klassen MacroCommand, Berechnung und Reset umgesetzt.
public interface Command
{

public void execute();

public void undo();
}
</code=java>

Klasse "Berechnung" ist ein konkreter Befehl, um eine arithmetische Operation zu berechnen:

<code=java>
package command;

//eine konkreter Befehl, um eine arithmetische Operation zu berechnen
public class Berechnung implements Command
{

private Prozessor prozessor;
private String operator;
private double operand;

public Berechnung(final Prozessor prozessor, final String operator, final double operand)
{
this.prozessor = prozessor;
this.operator = operator;
this.operand = operand;
}

@Override
public void execute()
{
prozessor.berechnung(operator, operand);
}

@Override
public void undo()
{
switch (operator)
{
case "+":
prozessor.berechnung("-", operand);
break;
case "-":
prozessor.berechnung("+", operand);
break;
case "*":
prozessor.berechnung("/", operand);
break;
case "/":
prozessor.berechnung("*", operand);
break;
}
}

@Override
public String toString()
{
return operator + "" + operand;
}
}
</code=java>

Die Klasse "Reset" ist auch ein konkreter Befehl, der den Prozessor zurücksetzt:

<code=java>
package command;

//ein konkreter Befehl, der den Prozessor zurücksetzt:
public class Reset implements Command
{

private Prozessor prozessor;
private double resultat;

public Reset(final Prozessor prozessor)
{
this.prozessor = prozessor;
}

@Override
public void execute()
{
resultat = prozessor.getResultat();
prozessor.berechnung("-", resultat);
}

@Override
public void undo()
{
prozessor.berechnung("+", resultat);
}

@Override
public String toString()
{
return "Reset{" + resultat + '}';
}
}
</code=java>

Die Klasse "MacroCommand" kann eine Reihe von Befehlen ausführen, die als Parameter übergeben werden:

<code=java>
package command;

import java.util.Arrays;

public class MacroCommand implements Command
{

private final Command[] commands;

/**
* Ein MacroCommand kann eine Reihe von Befehlen ausführen, die als Parameter übergeben werden.
*
* @param commands eine Reihe von Befehlen
*/
public MacroCommand(final Command[] commands)
{
this.commands = commands;
}

@Override
public void execute()
{
for (int i = 0; i < commands.length; i++)
{
commands[i].execute();
}
}

@Override
public void undo()
{
for (int i = commands.length - 1; i >= 0; i--)
{
commands[i].undo();
}
}

@Override
public String toString()
{
return Arrays.toString(commands);
}
}
</code=java>

Die Klasse "Taschenrechner" ist ein Aufrufer von Befehlen; sie weiß, wie man Befehle ausführen und rückgängig machen kann:

<code=java>
package command;

import java.util.ArrayList;
import java.util.List;

public class Taschenrechner
{

private List<Command> undoable;
private int undoLevel;

/**
* Ein Taschenrechner der Befehle ausführen und rückgängig machen kann.
*/
public Taschenrechner()
{
undoable = new ArrayList<>(10);
undoLevel = 0;
}

/**
* Den Befehl ausführen, der als Parameter übergebn wird.
*
* @param command
*/
public void execute(final Command command)
{
System.out.print("Berechnung: ");
command.execute();
addUndoable(command);
}

/**
* Die als Parameter übergebene Anzahl von Befehlen rückgängig machen.
*
* @param number
*/
public void undo(final int number)
{
System.out.println("undo(" + number + "):");
for (int i = 0; i < number; i++)
{
if (undoLevel > 0)
{
Command commande = undoable.get(--undoLevel);
commande.undo();
}
}
}

/**
* Die als Parameter übergebene Anzahl von Befehlen wieder ausführen.
*
* @param number
*/
public void redo(final int number)
{
System.out.println("redo(" + number + "):");
for (int i = 0; i < number; i++)
{
if (undoLevel < undoable.size())
{
Command commande = undoable.get(undoLevel++);
commande.execute();
}
}
}

//private Servicemethode:
private void addUndoable(final Command command)
{
//die "undoable"-Liste dem aktuellen undoLevel anpassen:
int count = undoable.size() - undoLevel;
for (int i = 0; i < count; i++)
{
undoable.remove(undoable.size() - 1);
}
//den neuen Befehl hinzufügen:
undoable.add(command);
undoLevel = undoable.size();
}
}
</code=java>

Und schließlich ist hier die Starter-Klasse, zum Testen unseres kleinen Taschenrechners, der dynamisch mit verschiedenen Befehlen konfigurierbar ist:

<code=java>
package command;

public class Demo
{

public static void main(final String[] args)
{
Prozessor prozessor = new Prozessor();
Taschenrechner taschenrechner = new Taschenrechner();

taschenrechner.execute(new Berechnung(prozessor, "-", 4));
taschenrechner.execute(new Berechnung(prozessor, "*", 3));
taschenrechner.execute(new Berechnung(prozessor, "+", 14));
double resultat = prozessor.getResultat();

Command[] pi = new Command[]
{
new Reset(prozessor),
new Berechnung(prozessor, "+", 103993),
new Berechnung(prozessor, "/", 33102),
};

taschenrechner.execute(new MacroCommand(pi));
taschenrechner.execute(new Berechnung(prozessor, "+", resultat));

taschenrechner.undo(2);
taschenrechner.redo(1);

taschenrechner.execute(new Reset(prozessor));
}
}
</code=java>

Der Taschenrechner gibt dies auf der Konsole aus:

[[Datei:Taschenrechner.jpg]]

[[Kategorie:Java]]
[[Kategorie:Design Pattern]]
[[Kategorie:Design Patterns]]
[[Kategorie:Gang of Four Pattern]]

Command (Design Pattern)

2012-10-15T13:44:55Z

AndreUhres: Die Seite wurde neu angelegt: „Das Command Design Pattern kapselt eine Anfrage als ein Objekt, so dass wir unsere Kunden mit unterschiedlichen Anfragen parametrieren können, Anfragen in ein…“

Das Command Design Pattern kapselt eine Anfrage als ein Objekt, so dass wir unsere Kunden mit unterschiedlichen Anfragen parametrieren können, Anfragen in einer Warteschlange oder einem Journal ablegen können, und aufhebbare Operationen unterstützen können.

Das Command Design Pattern entkoppelt ein Objekt das eine Anfrage macht, von demjenigen der weiß, wie diese Anfrage auszuführen ist. Im Mittelpunkt dieser Entkopplung steht ein Kommando-Objekt, das einen Empfänger und eine Aktion (oder eine Reihe von Aktionen) kapselt. Ein Aufrufer (invoker) richtet eine Anfrage an ein Kommando-Objekt durch den Aufruf seiner execute()-Methode, die wiederum die Aktionen des Empfängers (receiver) aufruft. Aufrufer können mit unterschiedlichen Befehlen konfiguriert werden, auch dynamisch zur Laufzeit.

Die Befehle können auch eine "undo"-Funktion unterstützen (rückgängig machen), indem sie eine undo()-Methode umsetzen, die das Empfänger-Objekt wieder in seinen vorherigen Zustand bringt, d.h. in den Zustand vor dem letzten Aufruf der Methode execute().

Ein Makro-Kommando ist eine einfache Erweiterung eines Kommandos, so dass er mehrere Befehle aufrufen kann. Ebenso kann ein Makro-Kommando die undo-Funktion leicht unterstützen.

Kommandos können auch für die Umsetzung von Transaktions- und Logging-Systemen verwendet werden.

Stellen wir uns zum Beispiel einen Empfänger "Prozessor" vor, der arithmetische Operationen durchführen kann:

<code=java>
package command;

public class Prozessor
{

private double resultat;
private String operator;
private double operand;

/**
* Ein Prozessor für arithmetische Operationen
*/
public Prozessor(){
}

/**
* Berechnung von arithmetischen Operationen, wobei das Resultat kumuliert wird.
* Das aktuelle Resultat wir auf dem Bildschirm angezeigt
* und kann mit der Methode getResultat() abgefragt werden.
* @param operator addition=+, soustraction=-, multiplication=* division=/
* @param operand un nombre réel du type "double"
*/
public void berechnung(final String operator, final double operand)
{
this.operator = operator;
this.operand = operand;
switch (operator)
{
case "+":
resultat += operand;
break;
case "-":
resultat -= operand;
break;
case "*":
resultat *= operand;
break;
case "/":
resultat /= operand;
break;
}
System.out.println(this);
}

public double getResultat()
{
return resultat;
}

@Override
public String toString()
{
return operator + " " + operand + " = " + resultat;
}
}
</code=java>

Die Schnittstelle "Command" ermöglicht es eine Aktion auf dem Prozessor auszuführen und rückgängig zu machen. Sie ist sehr einfach:

<code=java>
package command;

//Die Schnittstelle Command wird von den Klassen MacroCommand, Berechnung und Reset umgesetzt.
public interface Command
{

public void execute();

public void undo();
}
</code=java>

Klasse "Berechnung" ist ein konkreter Befehl, um eine arithmetische Operation zu berechnen:

<code=java>
package command;

//eine konkreter Befehl, um eine arithmetische Operation zu berechnen
public class Berechnung implements Command
{

private Prozessor prozessor;
private String operator;
private double operand;

public Berechnung(final Prozessor prozessor, final String operator, final double operand)
{
this.prozessor = prozessor;
this.operator = operator;
this.operand = operand;
}

@Override
public void execute()
{
prozessor.berechnung(operator, operand);
}

@Override
public void undo()
{
switch (operator)
{
case "+":
prozessor.berechnung("-", operand);
break;
case "-":
prozessor.berechnung("+", operand);
break;
case "*":
prozessor.berechnung("/", operand);
break;
case "/":
prozessor.berechnung("*", operand);
break;
}
}

@Override
public String toString()
{
return operator + "" + operand;
}
}
</code=java>

Die Klasse "Reset" ist auch ein konkreter Befehl, der den Prozessor zurücksetzt:

<code=java>
package command;

//ein konkreter Befehl, der den Prozessor zurücksetzt:
public class Reset implements Command
{

private Prozessor prozessor;
private double resultat;

public Reset(final Prozessor prozessor)
{
this.prozessor = prozessor;
}

@Override
public void execute()
{
resultat = prozessor.getResultat();
prozessor.berechnung("-", resultat);
}

@Override
public void undo()
{
prozessor.berechnung("+", resultat);
}

@Override
public String toString()
{
return "Reset{" + resultat + '}';
}
}
</code=java>

Die Klasse "MacroCommand" kann eine Reihe von Befehlen ausführen, die als Parameter übergeben werden:

<code=java>
package command;

import java.util.Arrays;

public class MacroCommand implements Command
{

private final Command[] commands;

/**
* Ein MacroCommand kann eine Reihe von Befehlen ausführen, die als Parameter übergeben werden.
*
* @param commands eine Reihe von Befehlen
*/
public MacroCommand(final Command[] commands)
{
this.commands = commands;
}

@Override
public void execute()
{
for (int i = 0; i < commands.length; i++)
{
commands[i].execute();
}
}

@Override
public void undo()
{
for (int i = commands.length - 1; i >= 0; i--)
{
commands[i].undo();
}
}

@Override
public String toString()
{
return Arrays.toString(commands);
}
}
</code=java>

Die Klasse "Taschenrechner" ist ein Aufrufer von Befehlen; sie weiß, wie man Befehle ausführen und rückgängig machen kann:

<code=java>
package command;

import java.util.ArrayList;
import java.util.List;

public class Taschenrechner
{

private List<Command> undoable;
private int undoLevel;

/**
* Ein Taschenrechner der Befehle ausführen und rückgängig machen kann.
*/
public Taschenrechner()
{
undoable = new ArrayList<>(10);
undoLevel = 0;
}

/**
* Den Befehl ausführen, der als Parameter übergebn wird.
*
* @param command
*/
public void execute(final Command command)
{
System.out.print("Berechnung: ");
command.execute();
addUndoable(command);
}

/**
* Die als Parameter übergebene Anzahl von Befehlen rückgängig machen.
*
* @param number
*/
public void undo(final int number)
{
System.out.println("undo(" + number + "):");
for (int i = 0; i < number; i++)
{
if (undoLevel > 0)
{
Command commande = undoable.get(--undoLevel);
commande.undo();
}
}
}

/**
* Die als Parameter übergebene Anzahl von Befehlen wieder ausführen.
*
* @param number
*/
public void redo(final int number)
{
System.out.println("redo(" + number + "):");
for (int i = 0; i < number; i++)
{
if (undoLevel < undoable.size())
{
Command commande = undoable.get(undoLevel++);
commande.execute();
}
}
}

//private Servicemethode:
private void addUndoable(final Command command)
{
//die "undoable"-Liste dem aktuellen undoLevel anpassen:
int count = undoable.size() - undoLevel;
for (int i = 0; i < count; i++)
{
undoable.remove(undoable.size() - 1);
}
//den neuen Befehl hinzufügen:
undoable.add(command);
undoLevel = undoable.size();
}
}
</code=java>

Und schließlich ist hier die Starter-Klasse, zum Testen unseres kleinen Taschenrechners, der dynamisch mit verschiedenen Befehlen konfigurierbar ist:

<code=java>
package command;

public class Demo
{

public static void main(final String[] args)
{
Prozessor prozessor = new Prozessor();
Taschenrechner taschenrechner = new Taschenrechner();

taschenrechner.execute(new Berechnung(prozessor, "-", 4));
taschenrechner.execute(new Berechnung(prozessor, "*", 3));
taschenrechner.execute(new Berechnung(prozessor, "+", 14));
double resultat = prozessor.getResultat();

Command[] pi = new Command[]
{
new Reset(prozessor),
new Berechnung(prozessor, "+", 103993),
new Berechnung(prozessor, "/", 33102),
};

taschenrechner.execute(new MacroCommand(pi));
taschenrechner.execute(new Berechnung(prozessor, "+", resultat));

taschenrechner.undo(2);
taschenrechner.redo(1);

taschenrechner.execute(new Reset(prozessor));
}
}
</code=java>

Der Taschenrechner gibt dies auf der Konsole aus:

[[Datei:Taschenrechner.jpg]]

[[Kategorie:Java]]
[[Kategorie:Design Pattern]]
[[Kategorie:Design Patterns]]
[[Kategorie:Gang of Four Pattern]]

2012-10-11T00:55:05Z

AndreUhres:

Seit Java 1.5 wird das Drucken der JTable unterstützt.

== [http://download.oracle.com/javase/6/docs/api/javax/swing/JTable.html#print%28%29 '''1. Die standard Druckfunktion'''] ==

print()

print(JTable.PrintMode)

print(JTable.PrintMode, MessageFormat, MessageFormat)

print(JTable.PrintMode, MessageFormat, MessageFormat, boolean, PrintRequestAttributeSet, boolean)

'''print(JTable.PrintMode, MessageFormat, MessageFormat, boolean, PrintRequestAttributeSet, boolean, PrintService)''' (seit 1.6)

'''JTable.PrintMode.NORMAL''' druckt die JTable mit der aktuellen Grösse.
'''JTable.PrintMode.FIT_WIDTH''' verkleinert die JTable, wenn nötig, so daß alle Spalten auf eine Seite passen.

'''Header und Footer Text''' kann hinzugefügt werden (ansonsten einfach null angeben);
im MessageFormat kann man als ArgumentIndex 0 für die Seitennummer angegeben:
<code=java>
new MessageFormat("Page {0}")
</code=java>

Mit dem '''ersten boolean''' Parameter kann man angeben ob der '''Druckdialog''' angezeigt werden soll oder nicht.

'''PrintRequestAttributeSet''' ermöglicht die direkte Angabe von Druckattributen.

Wenn der '''zweite boolean''' true ist (empfohlen), wird während des Druckvorgangs
ein modaler '''Progressdialog''' angezeigt, mit Abbruchmöglichkeit.

'''Printservice''' (seit 1.6) ist der PrintService der zum Drucken benutzt werden soll,
oder '''null''' zum Drucken auf den Standarddrucker.

== '''2. Das Anpassen der Druckfunktion''' ==

Folgende Methode ist verfügbar für erweiterte Druckanforderungen:

'''getPrintable(JTable.PrintMode, MessageFormat, MessageFormat)'''

Unten ist ein Demoprogramm das zeigt, wie man die JTable Druckfunktion anpassen kann.
Als Beispiel drucken wir einen Reportheader mit zwei Zeilen und Rand.

== '''3. Das Tutorial von Sun''' ==

Ein sehr gutes Tutorial über das Drucken von Tabellen, mit weiteren Einzelheiten: [http://download.oracle.com/javase/tutorial/uiswing/misc/printtable.html How to Print Tables]

== '''4. Demoprogramm das zeigt, wie man die JTable Druckfunktion anpassen kann''' ==

[[Datei:TableReportDemo1.jpg]]

Das Druckbild sieht dann etwa so aus (zwei Seiten):

[[Datei:TableReportDemo2.jpg]]

<code=java>
/*
* TableReportDemo.java This demo shows you how to customize the JTable print
* function. As an example, we print a report header with two rows and a border.
*/
import java.awt.*;
import java.awt.event.ActionEvent;
import java.awt.print.*;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.print.attribute.HashPrintRequestAttributeSet;
import javax.print.attribute.Size2DSyntax;
import javax.print.attribute.standard.MediaPrintableArea;
import javax.print.attribute.standard.MediaSize;
import javax.print.attribute.standard.MediaSizeName;
import javax.print.attribute.standard.OrientationRequested;
import javax.swing.*;
import javax.swing.table.DefaultTableModel;

public final class TableReportDemo extends JFrame
{

private JTable table;
private JButton btPrint;
private Action printAction = new AbstractAction("Print...")
{

@Override
public void actionPerformed(final ActionEvent e)
{
try
{
print(table, new Insets(15, 15, 15, 15), true);
} catch (PrinterException ex)
{
Logger.getLogger(TableReportDemo.class.getName()).log(Level.SEVERE, null, ex);
}
}
};
private HashPrintRequestAttributeSet attr;

public TableReportDemo()
{
super("TableReportDemo");
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
btPrint = new JButton();
add(btPrint, BorderLayout.SOUTH);
btPrint.setAction(printAction);
add(new JScrollPane(createTable()), BorderLayout.CENTER);
pack();
}

public JTable createTable()
{
String[] title = new String[]
{
"Title A", "Title B", "Title C", "Title D", "Title E", "Title F", "Title G", "Title H", "Title I"
};
String[][] data = new String[][]
{
};
DefaultTableModel model = new DefaultTableModel(data, title);
table = new JTable(model);
table.setAutoResizeMode(JTable.AUTO_RESIZE_OFF);
for (int i = 0; i < 50; i++)
{
model.addRow(new String[]
{
String.valueOf(i), "", "", "", "", "", "", "", ""
});
}
return table;
}

private void print(final JTable table, final Insets insets, final boolean portrait) throws PrinterException
{
try
{
Printable printable = new TableReport(table);
PrinterJob job = PrinterJob.getPrinterJob();
job.setPrintable(printable);
// create an attribute set to store attributes from the print dialog
if (attr == null)
{
attr = new HashPrintRequestAttributeSet();
float leftMargin = insets.left;
float rightMargin = insets.right;
float topMargin = insets.top;
float bottomMargin = insets.bottom;
if (portrait)
{
attr.add(OrientationRequested.PORTRAIT);
}
else
{
attr.add(OrientationRequested.LANDSCAPE);
leftMargin = insets.top;
rightMargin = insets.bottom;
topMargin = insets.right;
bottomMargin = insets.left;
}
attr.add(MediaSizeName.ISO_A4);
MediaSize mediaSize = MediaSize.ISO.A4;
float mediaWidth = mediaSize.getX(Size2DSyntax.MM);
float mediaHeight = mediaSize.getY(Size2DSyntax.MM);
attr.add(new MediaPrintableArea(
leftMargin, topMargin,
(mediaWidth - leftMargin - rightMargin),
(mediaHeight - topMargin - bottomMargin), Size2DSyntax.MM));
} // display a print dialog and record whether or not the user cancels it
boolean printAccepted = job.printDialog(attr);
if (printAccepted)
{// if the user didn't cancel the dialog
job.print(attr);// do the printing
}
} finally
{
// possibly restore the original table state here
}
}

public static void main(final String[] args)
{
Runnable gui = new Runnable()
{

@Override
public void run()
{
try
{
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (ClassNotFoundException | InstantiationException | IllegalAccessException | UnsupportedLookAndFeelException ex)
{
Logger.getLogger("log").log(Level.OFF, ex.getMessage());
}
new TableReportDemo().setVisible(true);
}
};
//GUI must start on EventDispatchThread:
SwingUtilities.invokeLater(gui);
}
}

class TableReport implements Printable
{

private Printable tablePrintable;
private PageFormat pageFormatJTable;

TableReport(final JTable table)
{
tablePrintable = table.getPrintable(JTable.PrintMode.FIT_WIDTH, null, null);
}

@Override
public int print(final Graphics graphics, final PageFormat pageFormat,
final int pageIndex) throws PrinterException
{
Graphics2D g = (Graphics2D) graphics;
int x1 = (int) pageFormat.getImageableX();
int y1 = (int) pageFormat.getImageableY();
int w1 = (int) pageFormat.getImageableWidth();
int h1 = (int) pageFormat.getImageableHeight();
if (pageFormatJTable == null)
{
pageFormatJTable = (PageFormat) pageFormat.clone();
Paper paperJTable = pageFormatJTable.getPaper();
if (pageFormatJTable.getOrientation() == PageFormat.PORTRAIT)
{
paperJTable.setImageableArea(x1, y1 + 60,//skip header area
w1, h1 - 90);//reserve space for header and footer
}
else
{
paperJTable.setImageableArea(y1 + 60, x1,//skip header area
h1 - 90, w1);//reserve space for header and footer
}
pageFormatJTable.setPaper(paperJTable);
}
String title = "Title";
String subtitle = "Subtitle";
Font f = g.getFont();
g.setFont(g.getFont().deriveFont(15f));
FontMetrics fm = g.getFontMetrics();
g.drawString(title, x1 + (w1 - fm.stringWidth(title)) / 2, y1 + 15);
g.setFont(f);
fm = g.getFontMetrics();
g.drawString(subtitle, x1 + (w1 - fm.stringWidth(subtitle)) / 2, y1 + 30);
g.drawRect(x1, y1, w1, 40);
String footer = "Page " + (pageIndex + 1);
g.drawString(footer, x1 + (w1 - fm.stringWidth(footer)) / 2, y1 + h1 - 10);
//print the table:
Graphics gCopy = g.create();
int retVal = tablePrintable.print(gCopy, pageFormatJTable, pageIndex);
gCopy.dispose();
//
return retVal;
}
}

</code=java>

[[Kategorie:Java]]
[[Kategorie:Tutorials (Java)]]
[[Kategorie:Swing]]
[[Kategorie:Java-Codeschnipsel]]
[[Kategorie:JTable]]

2012-02-17T08:19:51Z

AndreUhres:

__TOC__
==Das Konzept der Schnittstellen in der Programmierung mit Java==

Schnittstellen sind die Verbindung eines Objektes zum Benutzercode. Dieser kann dann zu den Schnittstellen programmieren, ohne sich um die versteckte Implementierung des Objekts kümmern zu müssen:

[[Datei:Schnittstellen.JPG]]

In [[Java|Java]] gibt es '''[[Methode_(Java)#abstrakte_Methoden|abstrakte Methoden]]''', mit denen wir die Schnittstellen von ihrer Implementierung trennen können. Eine abstrakte Methode ist ein Methodenkopf ohne Rumpf. Sie wird mit "public/protected abstract" gekennzeichnet und kann in einem [[Interface_(Java)|Interface]] oder in einer [[abstrakte_Klasse_(Java)|abstrakten Basisklasse]] deklariert werden. Das Interface (oder die abstrakte Basisklasse) stellt dann seinerseits einen '''abstrakten Obertyp''' dar. Beispiel:

[[Datei:Paintable.JPG]]

Wenn der deklarierte Typ einer Variablen vom abstrakten Obertyp ist, können wir seinen '''Polymorphismus''' nutzen, ohne uns um die konkreten Untertypen kümmern zu müssen. Die Objekte, die der Variablen zur Laufzeit zugewiesenen werden, können von irgendeinem Untertyp sein, über den der Benutzercode nichts wissen muss:

[[Datei:Benutzercode.JPG]]

In Java hängt das Konzept der Schnittstellen also eng zusammen mit den Begriffen '''abstrakte Methode''', '''abstrakter Obertyp''' (Interface oder abstrakte Basisklasse) und '''Polymorphismus'''. Es ermöglicht das Programmieren zu den Schnittstellen, ohne Festlegung von konkreten Implementierungen. Dadurch ist der Benutzercode weniger anfällig für Veränderungen in den Einzelheiten der Implementierung.

==Sprachgebrauch==

Das Wort '''Schnittstelle''' ist im Java-Sprachgebrauch überladen. Im vorliegenden Artikel hat es die Bedeutung von '''abstrakte Methode'''. Daneben wird es aber auch oft als deutsche Übersetzung für das Java-Konstrukt '''interface''' benutzt. Einerseits macht das Sinn, da ein "interface" ja abstrakte Methoden enthält, andererseits passt es aber nur bedingt, weil eine '''abstrakte Basisklasse''' ebenfalls abstrakte Methoden enthält. Im vorliegenden Artikel werden deshalb die Begriffe "interface" und "abstrakte Basisklasse" unter dem allgemeineren Begriff '''abstrakter Obertyp''' zusammengefasst. Der Begriff "abstrakter Obertyp" bietet zudem eine ideale Überleitung zum '''Polymorphismus''', der ja die Beziehungen zwischen Ober- und Untertypen beschreibt.

==Siehe auch==

http://www.java-forum.org/einfuehrungen-erste-schritte/117297-interfaces.html

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]
[[Kategorie:Tutorials (Java)]]

Datei:Schnittstellen.JPG

2012-02-14T10:13:21Z

AndreUhres: hat eine neue Version von „Datei:Schnittstellen.JPG“ hochgeladen

Datei:Benutzercode.JPG

2012-02-14T09:28:10Z

AndreUhres: hat eine neue Version von „Datei:Benutzercode.JPG“ hochgeladen

Datei:Paintable.JPG

2012-02-14T08:53:57Z

AndreUhres: hat eine neue Version von „Datei:Paintable.JPG“ hochgeladen

Schnittstellen

2012-02-11T07:22:11Z

AndreUhres: /* Sprachgebrauch */

__TOC__
==Das Konzept der Schnittstellen in der Programmierung mit Java==

Schnittstellen sind die Verbindung eines Objektes zum Benutzercode. Dieser kann dann zu den Schnittstellen programmieren, ohne sich um die versteckte Implementierung des Objekts kümmern zu müssen:

[[Datei:Schnittstellen.JPG]]

In [[Java|Java]] gibt es '''[[Methode_(Java)#abstrakte_Methoden|abstrakte Methoden]]''', mit denen wir die Schnittstellen von ihrer Implementierung trennen können. Eine abstrakte Methode ist ein Methodenkopf ohne Rumpf. Sie wird mit "public/protected abstract" gekennzeichnet und kann in einem [[Interface_(Java)|Interface]] oder in einer [[abstrakte_Klasse_(Java)|abstrakten Basisklasse]] deklariert werden. Das Interface (oder die abstrakte Basisklasse) stellt dann seinerseits einen '''abstrakten Obertyp''' dar. Beispiel:

[[Datei:Paintable.JPG]]

Wenn der deklarierte Typ einer Variablen vom abstrakten Obertyp ist, können wir seinen '''Polymorphismus''' nutzen, ohne uns um die konkreten Untertypen kümmern zu müssen. Die Objekte, die der Variablen zur Laufzeit zugewiesenen werden, können von irgendeinem Untertyp sein, über den der Benutzercode nichts wissen muss:

[[Datei:Benutzercode.JPG]]

In Java hängt das Konzept der Schnittstellen also eng zusammen mit den Begriffen '''abstrakte Methode''', '''abstrakter Obertyp''' (Interface oder abstrakte Basisklasse) und '''Polymorphismus'''. Es ermöglicht das Programmieren zu den Schnittstellen, ohne Festlegung von konkreten Implementierungen. Dadurch ist der Benutzercode weniger anfällig für Veränderungen in den Einzelheiten der Implementierung.

==Sprachgebrauch==

Das Wort '''Schnittstelle''' ist im Java-Sprachgebrauch überladen. Im vorliegenden Artikel hat es die Bedeutung von '''abstrakte Methode'''. Daneben wird es aber auch oft als deutsche Übersetzung für das Java-Konstrukt '''interface''' benutzt. Einerseits macht das Sinn, da ein "interface" ja abstrakte Methoden enthält, andererseits passt es aber nur bedingt, weil eine '''abstrakte Basisklasse''' ebenfalls abstrakte Methoden enthält. Im vorliegenden Artikel werden deshalb die Begriffe "interface" und "abstrakte Basisklasse" unter dem allgemeineren Begriff '''abstrakter Obertyp''' zusammengefasst. Der Begriff "abstrakter Obertyp" bietet zudem eine ideale Überleitung zum '''Polymorphismus''', der ja die Beziehungen zwischen Ober- und Untertypen beschreibt.

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]
[[Kategorie:Tutorials (Java)]]

Schnittstellen

2012-02-11T06:47:42Z

AndreUhres: /* Das Konzept der Schnittstellen in der Programmierung mit Java */

__TOC__
==Das Konzept der Schnittstellen in der Programmierung mit Java==

Schnittstellen sind die Verbindung eines Objektes zum Benutzercode. Dieser kann dann zu den Schnittstellen programmieren, ohne sich um die versteckte Implementierung des Objekts kümmern zu müssen:

[[Datei:Schnittstellen.JPG]]

In [[Java|Java]] gibt es '''[[Methode_(Java)#abstrakte_Methoden|abstrakte Methoden]]''', mit denen wir die Schnittstellen von ihrer Implementierung trennen können. Eine abstrakte Methode ist ein Methodenkopf ohne Rumpf. Sie wird mit "public/protected abstract" gekennzeichnet und kann in einem [[Interface_(Java)|Interface]] oder in einer [[abstrakte_Klasse_(Java)|abstrakten Basisklasse]] deklariert werden. Das Interface (oder die abstrakte Basisklasse) stellt dann seinerseits einen '''abstrakten Obertyp''' dar. Beispiel:

[[Datei:Paintable.JPG]]

Wenn der deklarierte Typ einer Variablen vom abstrakten Obertyp ist, können wir seinen '''Polymorphismus''' nutzen, ohne uns um die konkreten Untertypen kümmern zu müssen. Die Objekte, die der Variablen zur Laufzeit zugewiesenen werden, können von irgendeinem Untertyp sein, über den der Benutzercode nichts wissen muss:

[[Datei:Benutzercode.JPG]]

In Java hängt das Konzept der Schnittstellen also eng zusammen mit den Begriffen '''abstrakte Methode''', '''abstrakter Obertyp''' (Interface oder abstrakte Basisklasse) und '''Polymorphismus'''. Es ermöglicht das Programmieren zu den Schnittstellen, ohne Festlegung von konkreten Implementierungen. Dadurch ist der Benutzercode weniger anfällig für Veränderungen in den Einzelheiten der Implementierung.

==Sprachgebrauch==

Das Wort '''Schnittstelle''' ist im Java-Sprachgebrauch überladen. Im vorliegenden Artikel hat es die Bedeutung von '''abstrakte Methode'''. Daneben wird es aber auch oft als deutsche Übersetzung für das Java-Konstrukt '''interface''' benutzt. Einerseits macht das Sinn, da ein "interface" ja abstrakte Methoden enthält, andererseits passt es aber nur bedingt, weil eine '''abstrakte Basisklasse''' ebenfalls abstrakte Methoden enthält. Im vorliegenden Artikel werden deshalb die Begriffe "interface" und "abstrakte Basisklasse" unter dem allgemeineren Begriff '''abstrakter Obertyp''' zusammengefasst.

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]
[[Kategorie:Tutorials (Java)]]

Schnittstellen

2012-02-09T10:39:15Z

AndreUhres: /* Das Konzept der Schnittstellen in der Programmierung mit Java */

==Das Konzept der Schnittstellen in der Programmierung mit Java==

Schnittstellen sind die Verbindung eines Objektes zum Benutzercode. Dieser kann dann zu den Schnittstellen programmieren, ohne sich um die versteckte Implementierung des Objekts kümmern zu müssen:

[[Datei:Schnittstellen.JPG]]

In [[Java|Java]] gibt es '''[[Methode_(Java)#abstrakte_Methoden|abstrakte Methoden]]''', mit denen wir die Schnittstellen von ihrer Implementierung trennen können. Eine abstrakte Methode ist ein Methodenkopf ohne Rumpf. Sie wird mit "public/protected abstract" gekennzeichnet und kann in einem [[Interface_(Java)|Interface]] oder in einer [[abstrakte_Klasse_(Java)|abstrakten Basisklasse]] deklariert werden. Das Interface (oder die abstrakte Basisklasse) stellt dann seinerseits einen '''abstrakten Obertyp''' dar. Beispiel:

[[Datei:Paintable.JPG]]

Wenn der deklarierte Typ einer Variablen vom abstrakten Obertyp ist, können wir seinen '''Polymorphismus''' nutzen, ohne uns um die konkreten Untertypen kümmern zu müssen. Die Objekte, die der Variablen zur Laufzeit zugewiesenen werden, können von irgendeinem Untertyp sein, über den der Benutzercode nichts wissen muss:

[[Datei:Benutzercode.JPG]]

In Java hängt das Konzept der Schnittstellen also eng zusammen mit den Begriffen '''abstrakte Methode''', '''abstrakter Obertyp''' (Interface oder abstrakte Basisklasse) und '''Polymorphismus'''. Es ermöglicht das Programmieren zu den Schnittstellen, ohne Festlegung von konkreten Implementierungen. Dadurch ist der Benutzercode weniger anfällig für Veränderungen in den Einzelheiten der Implementierung.

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]
[[Kategorie:Tutorials (Java)]]

Schnittstellen

2012-02-09T08:30:38Z

AndreUhres:

==Das Konzept der Schnittstellen in der Programmierung mit Java==

Schnittstellen sind die Verbindung eines Objektes zum Benutzercode. Dieser kann dann zu den Schnittstellen programmieren, ohne sich um die versteckte Implementierung des Objekts kümmern zu müssen:

[[Datei:Schnittstellen.JPG]]

In [[Java|Java]] gibt es '''[[Methode_(Java)#abstrakte_Methoden|abstrakte Methoden]]''', mit denen wir die Schnittstellen von ihrer Implementierung trennen können. Eine abstrakte Methode ist ein Methodenkopf ohne Rumpf. Sie wird mit "public/protected abstract" gekennzeichnet und kann in einem [[Interface_(Java)|Interface]] oder in einer [[abstrakte_Klasse_(Java)|abstrakten Basisklasse]] deklariert werden. Das Interface (oder die abstrakte Basisklasse) stellt dann seinerseits einen '''abstrakten Obertyp''' dar. Beispiel:

[[Datei:Paintable.JPG]]

Wenn der deklarierte Typ einer Variablen vom abstrakten Obertyp ist, können wir seinen '''Polymorphismus''' nutzen, ohne uns um die konkreten Untertypen kümmern zu müssen. Die Objekte, die der Variablen zur Laufzeit zugewiesenen werden, können von irgendeinem Untertyp sein, über den der Benutzercode nichts wissen muss:

[[Datei:Benutzercode.JPG]]

In Java hängt das Konzept der Schnittstellen also eng zusammen mit den Begriffen '''abstrakte Methode''', '''abstrakter Obertyp''' (Interface oder abstrakte Basisklasse) und '''Polymorphismus'''. Es ermöglicht das Programmieren zu den Schnittstellen, ohne Festlegung von konkreten Implementierungen.

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]
[[Kategorie:Tutorials (Java)]]

Datei:Benutzercode.JPG

2012-02-09T02:09:06Z

AndreUhres: hat eine neue Version von „Datei:Benutzercode.JPG“ hochgeladen

Schnittstellen

2012-02-09T01:39:09Z

Diskussion:JTable mit Buttons in Tabellenzellen

2012-01-29T07:34:53Z

AndreUhres: Die Seite wurde neu angelegt: „Ich habe versucht, die Verarbeitung von JTable Buttons in der Klasse ButtonHandler etwas zu vereinfachen. Es fällt auf, dass der Ansatz noch so aufwändig ist. D…“