# Fenster schließen - Listener



## Manuel_H (22. Mai 2012)

Hallo,

ich bin neu bei der OO-Programmierung. Ich versuche hier ein Fenster zu erzeugen und es dann per Mausklick zu schließen. Das ganze habe ich aus einem Tutorial. Folgende Fragen habe ich dazu:

1)Lasse ich das ganze im Eclipse-Debugger laufen und setze einen Toogle Punkt in die windowClosing-Methode, so sehe ich, dass das Programm niemals dort ankommt. Das Fenster schließt sich nicht, das Programm nicth beendet. Wieso?

2) Wie werden solche Methoden (Listener) überhaupt aufgerufen? Wird der gegenwärtige Ablauf unterbrochen und dann in die Mehode gesprungen? Wie funktioniert das ganze maschinennah? Ist das ein anderer Thread? Habe bisher nur prozedural programmiert und da fällt mir das umdenken noch etwas schwer.

3) Bei den Import-Kommandos meldet mir Eclipse einen Fehler falls ich nur ...awt.*; einbinde. Verlangt wird auch extra der WindowAdapter. Ich versteh nicht ganz wieso, ist gerade auch nicht mein Interesse, erwähne ich nur damit sich keiner wundert.

Danke für die Hilfe. 

Hier kommt der Quellcode:


```
import java.awt.*;
import java.awt.event.WindowAdapter;

import javax.media.opengl.*;
import javax.media.opengl.awt.GLCanvas;


import com.jogamp.newt.event.WindowEvent;
import com.jogamp.opengl.util.Animator;


public class OpenGLWindow {
   public static void main (String[] args){
	   
	   Frame frame =new Frame("Fountain");
	   GLCanvas canvas = new GLCanvas();
	   
	   
	   frame.add(canvas);

	   frame.setSize(400,600);
	   final Animator animator =new Animator(canvas);

	   
	   frame.addWindowListener(new WindowAdapter() {
		   public void windowClosing(WindowEvent e) {
			   animator.stop();
			   System.exit(0);
		   }
		   
		   
	   });
	   frame.setVisible(true);
	   animator.start();

	   
   }
}
```


----------



## SlaterB (22. Mai 2012)

die Imports sind auch gerade der Grund für den Fehler,
> com.jogamp.newt.event.WindowEvent
muss dir doch als komisch auffallen,

bei Adaptern ist es verhängnisvoll, dass nicht unbedingt die schon fertig leere Methode überschrieben wird,
stattdessen definierst du eine neue mit dem falschen WindowEvent als Parameter, diese unbekannte Methode wird natürlich nie vom Framework 
(ja, mit eigenen Thread, The Event Dispatch Thread (The Java™ Tutorials > Creating a GUI With JFC/Swing > Concurrency in Swing) ) aufgerufen

java.awt.event.WindowEvent 
wärs gewesen


----------



## xehpuk (23. Mai 2012)

Deswegen immer schön ein 
	
	
	
	





```
@Override
```
 an überschriebene Methoden setzen.


----------



## Vancold (23. Mai 2012)

Wenn du AWT verstanden hast benutze einfach Swing. 

Einfach vor jede Komponente J schreiben dann hast du Swing.

Der Frame also der JFrame hat nämlich die Methode setDefaultCloseOperation();

schaut so aus im Objekt:


```
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
```

Macht genau das was du eig. willst und brauchst keinen Listener 


Beispiel:

Frame  = AWT
JFrame = Swing

Button  = AWT
JButton = Swing

Panel  = AWT
JPanel = Swing



(Methoden sind eigentlich die selben nur du hast einiges mehr. Mit den Listener funktioniert auch gleich )


----------



## Manuel_H (23. Mai 2012)

Danke für die Antworten. Jetzt ist mir das ganze klarer. Ich vermute mal, dass dadurch, dass das WindowEvent in mehreren Bibliotheken drin ist, eclipse auch verlangt hat, dass ich den ganzen "Pfad" (java.awt.event.WindowEvent) angebe, oder? Anstatt einfach java.awt.*; , oder?

Ich muss sagen, dass prozedurale Programmierung etwas intuitiver ist, da weiß man immer wo man ist. Dass ich einfach eine Methode in den Quelltext schreibe und die dann bei Bedarf einfach aufgerufen wird... d.h. ja dass ich immer alle Listener und ähnliche Objekte etc. im Kopf haben muss und keine direkte Verlaufskontrolle habe. 

Daran muss ich mich wohl noch gewöhnen.

Grüße,
Manuel


----------



## NintendoLink07 (23. Mai 2012)

Das würde mit "java.awt.event.*;" funktionieren.
Aber "java.awt.event.WindowEvent;" würde natürlich auch gehen.


----------

