# Frame öffnet anderes Frame: Methode auslagern



## UnkiDunki (20. Feb 2009)

Hi,

ich habe Umsetzungsprobleme mit dem Auslagern einer Methode, die die Aufgabe hat aus einem Frame "oldFrame" heraus ein neues Frame "newFrame" zu öffnen, sich dabei zu "disablen" und erst beim Schließen des zweiten Frames sich wieder zu "enablen" und sich den Fokus zu holen.
Das Öffnen von Frames aus Frames findet bei mir sehr sehr häufig statt, so dass ich mich dazu entschloss dieses als Methode auszulagern.

Das ganze funktioniert auch, wenn auch nicht wirklich elegant (siehe nächster Codeauszug), allerdings verliere ich durch das Auslagern die Möglichkeit in der Methode 
	
	
	
	





```
windowClosing(...
```
 noch zusätzliche Methode aufrufen zu können, die von Klasse zu Klasse natürlich unterschiedlich sein können.


[HIGHLIGHT="Java"]public static void openFrame(final JFrame oldFrame, final JFrame newFrame){

		oldFrame.setEnabled(false);

		new JFrameShower(newFrame);

		newFrame.addWindowListener(new WindowAdapter() {
			public void windowClosing(final WindowEvent e) {
				newFrame.dispose();
				oldFrame.setEnabled(true);
				oldFrame.setState(Frame.NORMAL);
				oldFrame.requestFocus();
			}
		});
	}[/HIGHLIGHT]


Jemand einen Rat, wie ich dieses trotzdem auslagern kann und trotzdem noch beim Schließen individuelle Methoden aufrufen kann oder lohnt sich das Auslagern eigentlich nicht
und ich sollte z.B. "JFSettings" wie im ersten Quellcode einfach so behandeln:


[HIGHLIGHT="Java"]...
protected void buttonSettingsActionPerformed(ActionEvent evt) {
		setEnabled(false);
		final JFSettings frame = new JFSettings(this);

		new Methods.JFrameShower(frame);
		frame.addWindowListener(new WindowAdapter() {
			public void windowClosed(final WindowEvent e) {
				enableFrame();
                                // Moeglichkeit zu weiteren Methoden nach Schließen des Frames
			}
		});
	}		

	private void enableFrame() {
		this.setEnabled(true);
		this.setState(Frame.NORMAL);
		this.requestFocus();
	}
...
[/HIGHLIGHT]

Vielen Dank schon mal für eure Anregungen und etwaige Fragen.


----------



## André Uhres (21. Feb 2009)

1234567890


----------



## hdi (21. Feb 2009)

> Eine Swinganwendung hat immer nur einen einzigen JFrame. Für sekundäre Fenster nehmen wir JDialog



Verständnisfrage dazu:
Weil ein JFrame einen Thread am leben hält, und ein JDialog nicht?

Wenn das stimmt, kann man das ja nicht so pauschal sagen, oder?
Kann ja sein, dass auch mein "Sekundärfenster" nicht beendet werden
soll nur weil ich das "Primäre" schliesse.

Falls das alles nicht zutrifft: Was ist dann der Grund dafür?


----------



## André Uhres (21. Feb 2009)

1234567890


----------



## diggaa1984 (21. Feb 2009)

da war hier letztens jemand mit einem Bsp à la: 

JFrame für Menu-Screen (initialier Bildschirm zum Starten und Optionen etc. .. ich sag mal fälchschlicherweise "Splashscreen" mit n paar Möglichkeiten zu agieren) .. und beim Starten des Spiels öffnete sich nen neuer JFrame mit dem eigentlichen Spielgeschehen. Der "Splashframe" war dann weg.

Keine Ahnung wie ich das lösen würde, aber was wäre daran "verkehrt"?!


----------



## hdi (21. Feb 2009)

Weiss auch nicht, was das heissen soll "kein Platz mehr in der Anwendung".
Wieso nicht? Man _kann_ ja x JFrames öffnen, und es gibt da auch keine Exceptions oder sonstige Probleme (soweit ich weiss). Also was ist der Design-Grund, das man das halt üblicherweise nicht so tun soll?


----------



## SlaterB (21. Feb 2009)

Design ist die Frage, Design ist die Antwort

kennst du ein anderes Programm welches mehrere Fenster hat?
macht man eben nicht, z.B. schlecht in der Taskleiste anzuklicken

es verbietet dir keiner, aber es verbietet dir auch keiner, gelbe Schrift auf weißen Hintergrund anzuzeigen


----------



## hdi (21. Feb 2009)

> es verbietet dir auch keiner, gelbe Schrift auf weißen Hintergrund anzuzeigen


Man macht das nicht, weil es einen Grund hat: Man kann es schlecht lesen.



> z.B. schlecht in der Taskleiste anzuklicken


Ok, das wäre ein Grund, wenn auch ein ziemlich mickriger 
Also, was wären denn andere "z.B."?

Versteh mich nich falsch, ich glaub dir. Aber mein Gott, was ist der Grund.
Nur das mit der Taskleiste?


----------



## André Uhres (22. Feb 2009)

1234567890


----------



## UnkiDunki (22. Feb 2009)

Erst mal super, dass meine Frage so eine Diskussion zu Tage gebracht hat 



André Uhres hat gesagt.:


> Eine Swinganwendung hat immer nur einen einzigen JFrame. Für sekundäre Fenster nehmen wir JDialog und für Komponenten, die sich denselben Bildschirmplatz teilen, JTabbedPane oder CardLayout.



Ok... das wusste ich nicht und wird mir mit SlaterB's "mehreren Fenstern in der Taskleiste" auch klar. Es verliert sich wirklich an Übersichtlichkeit und kann dann z.B. je nach Anzahl der Ebenen wirklich auf der Taskleiste "zu viel des Guten" werden.
Würde aber wie einige anderen hier auch noch vielleicht ein, zwei Gründe mehr hören 



			
				diggaa1984 hat gesagt.:
			
		

> JFrame für Menu-Screen (initialier Bildschirm zum Starten und Optionen etc. .. ich sag mal fälchschlicherweise "Splashscreen" mit n paar Möglichkeiten zu agieren) .. und beim Starten des Spiels öffnete sich nen neuer JFrame mit dem eigentlichen Spielgeschehen. Der "Splashframe" war dann weg.



Ich nehme an, dass das dann in Ordnung geht, oder? Der "Splashframe" wird ja disposed und damit sichergestellt, dass immer nur noch ein einziges JFrame "geöffnet" ist...

Zurück zu meiner Anfangsfrage:
Wenn ein Fenster ein anderes aufruft und das aufrufende gesperrt werden soll, nehme ich also ein JDialog, wo das Sperren automatisch geschieht und sich auch die Geschichte mit dem Fokus von selbst erledigt.
Im Prinzip bräuchte ich das Aufrufen eines anderen Fensters dann auch nicht "auszulagern", da der Codeaufwand so wesentlich geringer ist und ich dann einfach direkt im aufrufenden Frame beim Schließen des Dialoges eine individuelle Funktion setzen kann ohne mir viel Umstände zu machen. Ist das korrekt?


----------



## hdi (22. Feb 2009)

> [...] nehme ich also ein JDialog, wo das Sperren automatisch geschieht und sich auch die Geschichte mit dem Fokus von selbst erledigt.



Ich weiss ja nicht wie der Default-Konstruktor von JDialog das macht, aber dieses "automatisch sperren" usw. ist einfach der Effekt von Modalität.
Und ein JDialog _kann_ modal sein. Man kann das per setModal(boolean) setzen,
und es gibt auch einen Konstruktor dem du das gleich mitgeben kannst.
Also wie gesagt, das muss nicht unbedingt automatisch so sein. JFrames können halt
nicht modal sein, sie haben diese Eigenschaft einfach nicht.


----------



## UnkiDunki (22. Feb 2009)

Klar, das "automatische Sperren" liegt beim JDialog an seiner Modalität und default wird ein aufrufendes JFrame gesperrt. Soll das nicht geschehen, setzt man setModel auf false;
Werde die ganze Geschichte mal morgen ausprobieren und ob es überhaupt Sinn macht (habe nämlich fast 3-stellig "neue Fenster"-Aufrufe) das ganze auszulagern. Vom Codeumfang und von der Übersichtlichkeit her...


----------



## André Uhres (23. Feb 2009)

1234567890


----------



## UnkiDunki (23. Feb 2009)

André Uhres hat gesagt.:


> Eine Swinganwendung mit mehreren JFrames ist gleich einem Auto mit mehreren Fahrgestellen. Jedes Kind weiss, daß sowas normalerweise unerwünscht ist. Da der Sachverhalt so trivial ist, wird wohl niemand noch große Begründungen dazu hören wollen.
> 
> http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/splashscreen/



Alles klar  Danke Dir! *duckundweg*


----------



## Vayu (23. Feb 2009)

wenn man etwas wie einen Frame im Frame benutzen will -> JInternalFrame


----------



## UnkiDunki (23. Feb 2009)

Stimmt. Allerdings empfiehlt es sich für meine Anwendung doch eher JDialogs zu verwenden. Haben ja genau das Verhalten, was ich haben möchte.

Noch mal zum SplashScreen und der korrekten Anwendung:

Habe in meiner main-Methode einige Dinge, die initialisiert werden, u.a. Datenbankverbindungsaufbau etc.
Diese Initialisierungen benötigen ja einiges an Zeit, die man durch das SplashScreen ja gut überbrücken kann.
Ist es dann korrekt, dass ich die Initialisierungen wie folgt realisiere:


```
SplashScreen splash = SplashScreen.getSplashScreen();
		
if(splash!=null){
			Graphics2D g = (Graphics2D)splash.createGraphics();
			Dimension size = splash.getSize();
                        ...
                        init(); // Initialisierungen
                    }
else init(); // Aufruf der Initialisierungen ohne SplashScreen 
...
```

Ist die Anwendung so korrekt?


----------



## André Uhres (23. Feb 2009)

1234567890


----------



## Ebenius (24. Feb 2009)

Ich will nicht abstreiten, dass in diesem konkreten Beispiel *ein* JFrame die richtige Wahl ist. Allerdings tummeln sich in diesem Thema einige sehr sonderbare Behauptungen die ich nicht so stehen lassen kann...


André Uhres hat gesagt.:


> Eine Swinganwendung hat immer nur einen einzigen JFrame. Für sekundäre Fenster nehmen wir JDialog und für Komponenten, die sich denselben Bildschirmplatz teilen, JTabbedPane oder CardLayout.


Das ist falsch. Darf ich an dieser Stelle mal an das SDI (Single Document Interface)-Konzept erinnern? Wenn ich in Word mehrere Dokumente aufmache, oder im OpenOffice, oder im Gimp mehrere Bilder, oder im Browser ein neues Fenster öffne, oder ... In all diesen Fällen habe ich für jedes Dokument ein eigenständiges Frame (in Swing JFrame) und keine Dialoge. Bei den Anwendungen oben handelt es sich nicht um Swing-Anwendungen. Wenn es welche wären würden sie jedoch mehrere JFrames benutzen. Die Wikipedia erklärt uns eigentlich ganz gut, wofür wir Dialoge nutzen.



SlaterB hat gesagt.:


> kennst du ein anderes Programm welches mehrere Fenster hat? macht man eben nicht [...]


Mir würden wahrscheinlich hunderte einfallen, alle SDI: 
M$ Outlook (jede editierte und jede mit Doppelklick geöffnete Mail ist ein Fenster mit separatem Doppelklick)
Internet Explorer (CTRL+N öffnet ein neues)
Mozilla FireFox (CTRL+N)
Opera (CTRL+N)
sämtliche OpenOffice-Anwendungen
sämtliche M$-Office-Anwendungen
ICQ
Kopete
KDE PIM
Eclipse (Zum Beispiel: Rechtsklick auf ein Projekt, "Open in New Window")
The Gimp (da ist jedes Bild ein Fenster, die Applikation hat zusätzlich ein eigenes)
Acrobat Reader
KPDF
...
Mehrere Fenster in einer Anwendung zu benutzen, beziehungsweise benutzen zu können, ist inzwischen von der Ausnahme zum Standard geworden.

Ein JDialog erhält übrigens die Applikation ebenso am Leben wie jedes andere java.awt.Window-Derivat (JFrame, JWindow, Window, ...). Window.dispose() sagt dazu: 





> Note: When the last displayable window within the Java virtual machine (VM) is disposed of, the VM may terminate. See AWT Threading Issues for more information.



Ebenius


----------



## André Uhres (24. Feb 2009)

1234567890


----------



## Ebenius (24. Feb 2009)

André Uhres hat gesagt.:


> Auch wenn viele den Zug benutzen wollen, bleibt ein Auto immer noch ein Auto.


Wie wahr wie wahr. 

YMMD,
Ebenius


----------



## André Uhres (24. Feb 2009)

1234567890


----------



## Ebenius (24. Feb 2009)

André Uhres hat gesagt.:


> Tja, Auto ist eben immer noch standard. Ein JFrame ist wohl doch benutzerfreundlicher als viele JFrames.


Hängt das nicht doch einfach vom Anwendungsfall ab? Wenn ich zwei PDF-Dokumente öffne und abwechselnd lese, dann habe ich lieber zwei Fenster offen, zwei Einträge in der Taskbar, beides mit ALT-Tab zu wechseln. Was ist daran weniger benutzerfreundlich, wenn ich doch der Benutzer bin und es überaus freundlich finde? 

Ebenius


----------



## André Uhres (24. Feb 2009)

1234567890


----------



## Ebenius (24. Feb 2009)

André Uhres hat gesagt.:


> Dsa kann man so machen, muss man aber nicht. Viele haben ja auch eine zweites Auto.


Eben. Kann man. Auch in Swing. Deshalb ist diese Aussage ja auch falsch:





André Uhres hat gesagt.:


> Eine Swinganwendung hat immer nur einen einzigen JFrame.


----------



## UnkiDunki (24. Feb 2009)

André Uhres hat gesagt.:


> ... Der splash screen wird automatisch geschlossen, wenn das Swingfenster erscheint.



Ok, alles klar. Das hatte ich nicht genau verstanden. Damit brauche ich mich damit ja dann eigentlich garnicht befassen, sofern ich also nichts am SplashScreen modifizieren möchte 
Sehr einfach zu bedienen das ganze...


----------



## André Uhres (26. Feb 2009)

1234567890


----------



## Ebenius (26. Feb 2009)

Gute Nacht.


----------

