Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Objektorientierte Beziehungsfragen
7 Ausnahmen müssen sein
8 Äußere.innere Klassen
9 Besondere Typen der Java SE
10 Generics<T>
11 Lambda-Ausdrücke und funktionale Programmierung
12 Architektur, Design und angewandte Objektorientierung
13 Die Klassenbibliothek
14 Einführung in die nebenläufige Programmierung
15 Einführung in Datenstrukturen und Algorithmen
16 Einführung in grafische Oberflächen
17 Einführung in Dateien und Datenströme
18 Einführung ins Datenbankmanagement mit JDBC
19 Einführung in <XML>
20 Testen mit JUnit
21 Bits und Bytes und Mathematisches
22 Die Werkzeuge des JDK
A Java SE Paketübersicht
Stichwortverzeichnis

Download:
- Beispielprogramme, ca. 20,0 MB
- Übungsaufgaben, ca. 1,8 MB
- Musterlösungen, ca. 0,8 MB

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenbloom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Rheinwerk Computing
1306 Seiten, gebunden, 11. Auflage
49,90 Euro, ISBN 978-3-8362-2873-2
Pfeil 16 Einführung in grafische Oberflächen
Pfeil 16.1 GUI-Frameworks
Pfeil 16.1.1 Kommandozeile
Pfeil 16.1.2 Grafische Benutzeroberfläche
Pfeil 16.1.3 Abstract Window Toolkit (AWT)
Pfeil 16.1.4 Java Foundation Classes und Swing
Pfeil 16.1.5 JavaFX
Pfeil 16.1.6 SWT (Standard Widget Toolkit) *
Pfeil 16.2 Deklarative und programmierte Oberflächen
Pfeil 16.2.1 GUI-Beschreibungen in JavaFX
Pfeil 16.2.2 Deklarative GUI-Beschreibungen für Swing?
Pfeil 16.3 GUI-Builder
Pfeil 16.3.1 GUI-Builder für JavaFX
Pfeil 16.3.2 GUI-Builder für Swing
Pfeil 16.4 Aller Swing-Anfang – Fenster zur Welt
Pfeil 16.4.1 Eine Uhr, bei der die Zeit nie vergeht
Pfeil 16.4.2 Swing-Fenster mit javax.swing.JFrame darstellen
Pfeil 16.4.3 Mit add(…) auf den Container
Pfeil 16.4.4 Fenster schließbar machen – setDefaultCloseOperation(int)
Pfeil 16.4.5 Sichtbarkeit des Fensters
Pfeil 16.4.6 Größe und Position des Fensters verändern
Pfeil 16.5 Beschriftungen (JLabel)
Pfeil 16.5.1 Mehrzeiliger Text, HTML in der Darstellung
Pfeil 16.6 Es tut sich was – Ereignisse beim AWT
Pfeil 16.6.1 Die Ereignisquellen und Horcher (Listener) von Swing
Pfeil 16.6.2 Listener implementieren
Pfeil 16.6.3 Listener bei dem Ereignisauslöser anmelden/abmelden
Pfeil 16.6.4 Adapterklassen nutzen
Pfeil 16.6.5 Innere Mitgliedsklassen und innere anonyme Klassen
Pfeil 16.6.6 Aufrufen der Listener im AWT-Event-Thread
Pfeil 16.7 Schaltflächen
Pfeil 16.7.1 Normale Schaltflächen (JButton)
Pfeil 16.7.2 Der aufmerksame ActionListener
Pfeil 16.7.3 Schaltflächen-Ereignisse vom Typ ActionEvent
Pfeil 16.7.4 Basisklasse AbstractButton
Pfeil 16.7.5 Wechselknopf (JToggleButton)
Pfeil 16.8 Alles Auslegungssache – die Layoutmanager
Pfeil 16.8.1 Übersicht über Layoutmanager
Pfeil 16.8.2 Zuweisen eines Layoutmanagers
Pfeil 16.8.3 Im Fluss mit FlowLayout
Pfeil 16.8.4 BoxLayout
Pfeil 16.8.5 Mit BorderLayout in alle Himmelsrichtungen
Pfeil 16.8.6 Rasteranordnung mit GridLayout
Pfeil 16.8.7 Weitere Layoutmanager
Pfeil 16.9 Textkomponenten
Pfeil 16.9.1 Text in einer Eingabezeile
Pfeil 16.9.2 Die Oberklasse der Textkomponenten (JTextComponent)
Pfeil 16.9.3 Geschützte Eingaben (JPasswordField)
Pfeil 16.9.4 Validierende Eingabefelder (JFormattedTextField)
Pfeil 16.9.5 Einfache mehrzeilige Textfelder (JTextArea)
Pfeil 16.10 Grundlegendes zum Zeichnen
Pfeil 16.10.1 Die paint(Graphics)-Methode für das AWT-Frame
Pfeil 16.10.2 Die ereignisorientierte Programmierung ändert Fensterinhalte
Pfeil 16.10.3 Zeichnen von Inhalten auf ein JFrame
Pfeil 16.10.4 Auffordern zum Neuzeichnen mit repaint(…)
Pfeil 16.10.5 Java 2D-API
Pfeil 16.11 Zum Weiterlesen
 
Zum Seitenanfang

16.6Es tut sich was – Ereignisse beim AWT Zur vorigen ÜberschriftZur nächsten Überschrift

Beim Arbeiten mit grafischen Oberflächen interagiert der Benutzer mit Komponenten. Er bewegt die Maus im Fenster, klickt eine Schaltfläche an oder verschiebt einen Rollbalken. Das grafische System beobachtet die Aktionen des Benutzers und informiert die Applikation über die anfallenden Ereignisse. Dann kann das laufende Programm entsprechend reagieren.

 
Zum Seitenanfang

16.6.1Die Ereignisquellen und Horcher (Listener) von Swing Zur vorigen ÜberschriftZur nächsten Überschrift

Im Ereignismodell von Java gibt es eine Reihe von Ereignisauslösern (Ereignisquellen, engl. event sources), wie zum Beispiel Schaltflächen oder Schieberegler. Die Ereignisse können vom Benutzer der grafischen Oberfläche kommen, etwa wenn er eine Schaltfläche anklickt, aber auch auf eigene Auslöser zurückzuführen sein, zum Beispiel wenn im Hintergrund eine Tabelle geladen wird.

Neben den Ereignisauslösern gibt es eine Reihe von Interessenten (Listener oder Horcher genannt), die gern informiert werden wollen, wenn ein Ereignis aufgetreten ist. Da der Interessent in der Regel nicht an allen ausgelösten Oberflächen-Ereignissen interessiert ist, sagt er einfach, welche Ereignisse er empfangen möchte. Dies funktioniert so, dass er sich bei einer Ereignisquelle anmeldet, und diese informiert ihn, wenn sie ein Ereignis aussendet. Auf diese Weise leidet die Systemeffizienz nicht, da nur diejenigen informiert werden, die auch Verwendung für das Ereignis haben. Für jedes Ereignis gibt es einen eigenen Listener, an den das Ereignis weitergeleitet wird – darum der Name für das Modell: Delegation Model[ 236 ]. Tabelle 16.1 gibt eine Übersicht über einige Listener und zeigt, was für Ereignisse sie melden:

Listener

Ereignisse

ActionListener

Der Benutzer aktiviert eine Schaltfläche bzw. ein Menü oder drückt (¢) auf einem Textfeld.

WindowListener

Der Benutzer schließt ein Fenster oder möchte es verkleinern.

MouseListener

Der Benutzer drückt auf eine Maustaste.

MouseMotionListener

Der Benutzer bewegt die Maus.

Tabelle 16.1Einige Listener und die von ihnen gemeldeten Ereignisse

Dem Listener übergibt das Swing-Grafiksystem jeweils ein Ereignis-Objekt, etwa dem ActionListener ein ActionEvent-Objekt, dem WindowListener ein WindowEvent-Objekt usw. Die Einzigen, die etwas aus der Reihe tanzen, sind MouseListener und MouseMotionListener, denn beide melden MouseEvent-Objekte.

Schritte zum richtigen Horchen

Damit die Quelle Ereignisse sendet und der Client darauf reagiert, sind zwei Schritte durchzuführen:

  1. Implementieren des Listeners

  2. Anmelden des Listeners

Um dieses Konzept kennenzulernen, wollen wir einen Fenster-Horcher programmieren, der registriert, ob ein Fenster geschlossen werden soll. Wenn ja, bietet er einen Dialog; bestätigt der Benutzer den Dialog, wird die Applikation beendet.

 
Zum Seitenanfang

16.6.2Listener implementieren Zur vorigen ÜberschriftZur nächsten Überschrift

Der Listener selbst ist eine Schnittstelle, die von den Interessenten implementiert wird. Da die Ereignis-Schnittstelle Callback-Methoden vorschreibt, muss der Interessent diese Operation implementieren. Wird im nächsten Schritt ein Horcher mit dem Ereignisauslöser verbunden, kann die Ereignisquelle davon ausgehen, dass der Horcher die entsprechende Methode besitzt. Diese ruft die Ereignisquelle bei einem Ereignis später auf.

Die Schnittstelle WindowListener

Alle Meldungen rund um Fenster werden über einen WindowListener abgewickelt. Implementierungen können so etwa erfahren, ob das Fenster vergrößert oder verkleinert wurde. Die Schnittstelle deklariert folgende Operationen:

interface java.awt.event.WindowListener
extends EventListener

  • void windowOpened(WindowEvent e)
    Wird aufgerufen, wenn das Fenster geöffnet wird.

  • void windowClosing(WindowEvent e)
    Wird aufgerufen, wenn das Fenster geschlossen wird.

  • void windowClosed(WindowEvent e)
    Wird aufgerufen, wenn das Fenster mit dispose() geschlossen wurde.

  • void windowIconified(WindowEvent e)
    Wird aufgerufen, wenn das Fenster zum Icon verkleinert wird.

  • void windowDeiconified(WindowEvent e)
    Wird aufgerufen, wenn das Fenster wieder hochgeholt wird.

  • void windowActivated(WindowEvent e)
    Wird aufgerufen, wenn das Fenster aktiviert wird.

  • void windowDeactivated(WindowEvent e)
    Wird aufgerufen, wenn das Fenster deaktiviert wird.

Der nächste Schritt ist, die Schnittstelle zu implementieren und in windowClosing(WindowEvent) Programmcode einzubetten, der den Benutzer fragt, ob die Anwendung wirklich geschlossen werden soll.

UML-Diagramm von WindowListener

Abbildung 16.3UML-Diagramm von WindowListener

Wer implementiert die Schnittstelle WindowListener?

Bei der Implementierung der Schnittstelle WindowListener gibt es unterschiedliche Varianten:

  • Eine Klasse, die zum Beispiel JFrame erweitert, implementiert gleichzeitig WindowListener.

  • Eine externe Klasse implementiert die Listener-Schnittstelle.

  • Eine innere anonyme Klasse implementiert den Listener.

Die Lösungen haben Vor- und Nachteile. Wenn die eigene Klasse den Listener implementiert, ist das Programm schön kurz und der Listener hat einfachen Zugriff auf alle Zustände oder Variablen. Den Listener von einer anderen Klasse implementieren zu lassen hat dagegen den Vorteil, dass die Implementierung wiederverwendbar ist. Das ist bei einem allgemeinen Horcher für Fensterschließereignisse sicherlich angebracht.

Fensterschließ-Horcher

Die Implementierung fragt mit JOptionPane.showConfirmDialog(…), ob das Fenster wirklich geschlossen werden soll. Die nicht genutzten Callback-Methoden implementieren wir leer.

Listing 16.3com/tutego/insel/ui/event/DialogWindowClosingListener.java

package com.tutego.insel.ui.event;

import java.awt.event.*;
import javax.swing.JOptionPane;

public class DialogWindowClosingListener implements WindowListener {
@Override public void windowClosing( WindowEvent event ) {
int option = JOptionPane.showConfirmDialog( null, "Applikation beenden?" );
if ( option == JOptionPane.OK_OPTION )
System.exit( 0 );
}

@Override public void windowClosed( WindowEvent event ) { /*Empty*/ }
@Override public void windowDeiconified( WindowEvent event ) { /*Empty*/ }
@Override public void windowIconified( WindowEvent event ) { /*Empty*/ }
@Override public void windowActivated( WindowEvent event ) { /*Empty*/ }
@Override public void windowDeactivated( WindowEvent event ) { /*Empty*/ }
@Override public void windowOpened( WindowEvent event ) { /*Empty*/ }
}

An diesem Beispiel ist abzulesen, dass jeder, der ein WindowListener sein möchte, die vorgeschriebenen Methoden implementieren muss. Damit zeigt er Interesse an dem WindowEvent. Bis auf windowClosing(…) haben wir die anderen Operationen nicht implementiert, da sie uns nicht interessieren. Die Implementierung ist so, dass die Anwendung beendet wird, wenn der Anwender auf das × klickt und den Dialog mit OK bestätigt.

 
Zum Seitenanfang

16.6.3Listener bei dem Ereignisauslöser anmelden/abmelden Zur vorigen ÜberschriftZur nächsten Überschrift

Hat der Listener die Schnittstelle implementiert, wird er mit dem Ereignisauslöser verbunden. Dafür gibt es eine Reihe von Hinzufügen- und Entfernen-Methoden, die einer Namenskonvention folgen:

  • addEreignisListener( EreignisListener )

  • removeEreignisListener( EreignisListener )

Üblicherweise lassen sich beliebig viele Listener an einen Ereignisauslöser hängen.

addXXXListener(…) nur dann möglich, wenn es auch Ereignisse gibt

Nicht jede Komponente kann jedes Ereignis auslösen. Daher gibt es nur addXXXListener(…) für Ereignisse, die die Komponenten tatsächlich auslösen, und unterschiedliche Komponenten bieten unterschiedliche Hinzufügen-Methoden. Die JFrame-Klasse bietet zum Beispiel addWindowListener(…) für Fensterereignisse, aber kein addActionListener(…) – das wiederum bietet JButton, damit er die Aktivierung der Schaltfläche melden kann. Eine Schaltfläche löst eben keine Fensterereignisse aus, und daher gibt es die Methode addWindowListener(…) bei Schaltflächen nicht. So lassen sich über die angebotenen addXXXListener(…)-Methoden gut die Ereignisse ablesen, die eine Komponente auslösen kann, denn das XXX wird dann nach der Namenskonvention der Ereignistyp sein.

Fensterschließer registrieren

Den Listener für Fensterereignisse, unseren DialogWindowClosingListener, binden wir mit der Methode addWindowListener(…) an ein Fenster. Wird genau dieses Fenster geschlossen, bekommen wir das mit und können reagieren.

Listing 16.4com/tutego/insel/ui/event/CloseWithDialogFrame.java

package com.tutego.insel.ui.event;

import javax.swing.*;

public class CloseWithDialogFrame {
public static void main( String[] args ) {
JFrame f = new JFrame();
f.setDefaultCloseOperation( JFrame.DO_NOTHING_ON_CLOSE );
f.add( new JLabel( "Zyklone bringen Regen" ) );
f.pack();
f.addWindowListener( new DialogWindowClosingListener() );
f.setVisible( true );
}
}

Wir tragen mit addWindowListener(…) den Listener ein. Immer wenn ein Window-Event ausgelöst wird, kümmert sich die jeweilige Methode um dessen Abarbeitung.

Normalerweise schließt Swing einen JFrame automatisch, wenn das × gedrückt wird – anders als beim AWT-Frame. Die Anweisung setDefaultCloseOperation(JFrame.DO_NOTHING_ON_ CLOSE) verändert dieses Standardverhalten, damit nichts passiert und wir selbst zu 100 % die Kontrolle behalten. Denn ist die Zeile nicht im Programm, so merkt Swing, dass das × gedrückt wurde, und versteckt das Fenster, egal, was der Benutzer im Dialog angibt.

 
Zum Seitenanfang

16.6.4Adapterklassen nutzen Zur vorigen ÜberschriftZur nächsten Überschrift

Hat eine Schnittstelle wie WindowListener viele Methoden, so hat eine Implementierung alle Methoden zu realisieren, auch wenn die Mehrzahl einen leeren Rumpf hat. Das ist lästig. Hier helfen Adapterklassen – Klassen, die die Schnittstellen mit leeren Rümpfen implementieren. Hat beispielsweise die Schnittstelle WindowListener sieben Methoden, so steht in der Adapterklasse folgende Implementierung:

Listing 16.5java.awt.event.WindowAdapter

public abstract class WindowAdapter
implements WindowListener, WindowStateListener, WindowFocusListener
{
public void windowOpened( WindowEvent e ) { }
public void windowClosing( WindowEvent e ) { }
public void windowClosed( WindowEvent e ) { }
public void windowIconified( WindowEvent e ) { }
public void windowDeiconified( WindowEvent e ) { }
public void windowActivated( WindowEvent e ) { }
public void windowDeactivated( WindowEvent e ) { }
public void windowStateChanged( WindowEvent e ) { }
public void windowGainedFocus( WindowEvent e ) { }
public void windowLostFocus( WindowEvent e ) { }
}

Zusätzlich entdecken wir einige Methoden, die nicht direkt von unserem WindowListener stammen, sondern von zwei weiteren Schnittstellen, die jetzt keine Rolle spielen.

UML-Diagramm von WindowAdapter

Abbildung 16.4UML-Diagramm von WindowAdapter

Wenn wir jetzt einen Ereignisbehandler implementieren müssen, erweitern wir einfach die Adapterklasse und überschreiben nur die relevanten Methoden. Der Listener zum Schließen des Fensters mit einer Adapterklasse sieht dann wie folgt aus:

Listing 16.6com/tutego/insel/ui/event/DialogWindowClosingListener2.java

package com.tutego.insel.ui.event;

import java.awt.event.*;
import javax.swing.JOptionPane;

public class DialogWindowClosingListener2 extends WindowAdapter {
@Override public void windowClosing( WindowEvent event ) {
int option = JOptionPane.showConfirmDialog( null, "Applikation beenden?" );
if ( option == JOptionPane.OK_OPTION )
System.exit( 0 );
}
}

Beim Client ändert sich nicht viel, es ist immer noch die addWindowListener(…)-Methode:

Listing 16.7com/tutego/insel/ui/event/CloseWithDialogFrame2.java, main()

JFrame f = new JFrame();
f.setDefaultCloseOperation( JFrame.DO_NOTHING_ON_CLOSE );
f.add( new JLabel( "Zyklone bringen Regen" ) );
f.pack();
f.addWindowListener( new DialogWindowClosingListener2() );
f.setVisible( true );
 
Zum Seitenanfang

16.6.5Innere Mitgliedsklassen und innere anonyme Klassen Zur vorigen ÜberschriftZur nächsten Überschrift

Wir haben für das Fensterschließ-Beispiel eine externe Klasse benutzt, weil die Klasse für unterschiedliche Swing-Programme nützlich ist. Ist der Listener sehr individuell und mit der Komponente verbunden, so sind innere anonyme Klassen nützlich. Dazu zwei Beispiele.

Auf Klicks reagieren

Das JLabel kann Maus-Ereignisse empfangen, was wir nutzen wollen, um bei einem Doppelklick die Applikation zu beenden:

Listing 16.8com/tutego/insel/ui/event/ClickOnJLabelToClose, java, main()

JFrame frame = new JFrame();
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );

JLabel label = new JLabel( "Lebe immer First-Class, sonst tun es deine Erben!" );
label.setForeground( Color.BLUE );

frame.add( label );

label.addMouseListener( new MouseAdapter() {
@Override public void mouseClicked( MouseEvent e ) {
if ( e.getClickCount() > 1 )
System.exit( 0 );
}
} );

frame.pack();
frame.setVisible( true );

Die Lösung hat den Vorteil, dass nicht extra eine eigene Klasse mit einem häufig überflüssigen Namen angelegt wird. Die Unterklasse von MouseAdapter ist nur hier sinnvoll und wird nur in diesem Kontext benötigt.

Dezimal-in-Hexadezimal-Umwandler

Innere Klassen sind elegant, denn sie können leicht auf Zustände der äußeren Klasse zugreifen. Das folgende Programm realisiert einen Hexadezimalwandler:

Listing 16.9com/tutego/insel/ui/event/HexConverter.java

package com.tutego.insel.ui.event;

import java.awt.FlowLayout;
import java.awt.event.*;
import javax.swing.*;

public class HexConverter {
public static void main( String[] args ) {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
frame.setLayout( new FlowLayout() );

final JTextField decTextField = new JTextField();
decTextField.setColumns( 5 );
frame.add( decTextField );
frame.add( new JLabel(" ist hexadezimal " ) );
final JTextField hexTextField = new JTextField();
hexTextField.setColumns( 5 );
frame.add( hexTextField );
JButton okButton = new JButton( "Konvertiere" );
frame.add( okButton );

okButton.addActionListener( new ActionListener() {
@Override public void actionPerformed( ActionEvent e ) {
int dec = Integer.parseInt( decTextField.getText() );
String hex = Integer.toHexString( dec );
hexTextField.setText( hex );
}
} );

frame.pack();
frame.setVisible( true );
}
}

Das Programm nutzt einige Dinge, die neu sind, aber gut verständlich: Damit mehrere Komponenten nebeneinandergesetzt werden, konfigurieren wir das Fenster mit einem FlowLayout. Dann platzieren wir ein Textfeld, eine Beschriftung, ein Textfeld und eine Schaltfläche nebeneinander. An die Schaltfläche kommt ein Listener, damit wir mitbekommen, ob sie bestätigt wurde. Wenn sie bestätigt wurde, erfolgt die Konvertierung (Fehler werden nicht abgefangen). Die anonyme Klasse kann dabei sehr gut auf die beiden Textfelder zurückgreifen. Wäre der Listener eine externe Klasse, so müssten ihr – etwa im Konstruktor – die beiden Textfelder mitgegeben werden.

 
Zum Seitenanfang

16.6.6Aufrufen der Listener im AWT-Event-Thread Zur vorigen ÜberschriftZur nächsten Überschrift

Nachdem der Listener implementiert und angemeldet wurde, ist das System im Fall eines aufkommenden Ereignisses bereit, es zu verteilen. Aktiviert zum Beispiel der Benutzer eine Schaltfläche, so führt der AWT-Event-Thread – auch Event-Dispatching-Thread genannt – den Programmcode im Listener selbstständig aus. Sehr wichtig ist Folgendes: Der Programmcode im Listener sollte nicht zu lange laufen, da sich sonst Ereignisse in der Queue sammeln, die der AWT-Thread nicht mehr verarbeiten kann. Diese Eigenschaft fällt dann schnell auf, wenn sich Aufforderungen zum Neuzeigen (Repaint-Ereignisse) aufstauen, da auf diese Weise leicht ein »stehendes System« entsteht.

Die Reihenfolge, in der die Listener abgearbeitet werden, ist im Prinzip undefiniert. Zwar reiht das JDK sie in eine Liste ein, sodass es dadurch eine Reihenfolge gibt, doch sollte diesem Implementierungsdetail keine Beachtung geschenkt werden.

 


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Zum Katalog
Zum Katalog: Java ist auch eine Insel Java ist auch eine Insel
Jetzt bestellen

 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java SE 8 Standard-Bibliothek
Java SE 8 Standard-Bibliothek


Zum Katalog: Professionell entwickeln mit Java EE 7
Professionell entwickeln mit Java EE 7


Zum Katalog: Schrödinger programmiert Java
Schrödinger programmiert Java


Zum Katalog: Einführung in Java
Einführung in Java


Zum Katalog: Programmieren lernen mit Java
Programmieren lernen mit Java


Zum Katalog: Apps entwickeln für Android 5
Apps entwickeln für Android 5


Zum Katalog: Apps entwickeln mit Android Studio
Apps entwickeln mit Android Studio


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2016
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 
Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de