2 JDialogs benutzen ein windowClosed()?

[UnkiDunki]

Hi,

mir ist eben etwas aufgefallen:
Ich lasse in einem JDialog A ein JDialog B aufrufen:

JDialogB dialog = new JDialogB(this, 0, false);
dialog.setVisible(true);
		
dialog.addWindowListener(new WindowAdapter() {
        public void windowClosed(final WindowEvent e) {
		System.out.println("Hi");
	}

Beim Schließen des JDialogs B wird ordnungsgemäß "Hi" ausgegeben.
Wenn ich jetzt aber JDialog A schließe, wird auch wieder "Hi" ausgegeben. Könnt ihr mir diesen Vorgang erklären und wie ich dieses unterbinde?

Danke im Voraus und liebe Grüße

 

[Schandro]

Poste mal mehr Code. Ich habs nicht geschafft das beschriebene Feature nachzubauen:

class DialogTest extends JDialog{
	
	public static void main(String[] args) {
		new DialogTest().showIt();
	}
	JDialog dialog2;
	
	public DialogTest(){
		super((Dialog)null,"1",false);		
		dialog2 = new JDialog(this,"2",false);
		
		dialog2.addWindowListener(new WindowAdapter(){
			public void windowClosed(WindowEvent e) {
				System.out.println("closed");
			}
			public void windowClosing(WindowEvent e) {
				System.out.println("closing");
			}
		});
	}
	
	public void showIt(){
		this.setVisible(true);
		dialog2.setVisible(true);
	}
}

=> es wird nur was ausgegeben wenn man "2" schließt. Wenn man zuerst "1" schließt werden beide geschlossen und nichts ausgegeben.

 

[UnkiDunki]

Ok, hoffe, dass der folgende Code jetzt richtig ist, weil einfach so posten kann ich ihn nicht, da er zu umfangreich ist und das Drumherum nur ablenken würde... Da habe ich jetzt das wesentliche (hoffentlich unverfälscht) herausgezogen:

public class JDialogA extends JDialog implements ActionListener, MouseListener, KeyListener{

public JDialogA(JDialog parent){
            super(parent, "DialogA", true);
...
            JDialogB dialog = new JDialogB(this, 2, true);
	    dialog.setVisible(true);
			
            dialog.addWindowListener(new WindowAdapter() {
		public void windowClosed(final WindowEvent e) {
			System.out.println("Hi");
			}
		});
...
}

Wie man sieht, wird DialogA von einem anderen JDialog aufgerufen, wie B von A, aber das ist denke ich mal nicht von Belang

 

[Wildcard]

Wie du an Schandros beispiel sieht funktioniert es auf diese Weise. Wenn es bei dir nicht funktioniert, dann tust du etwas anderes als in diesem Beispiel und aus deinem Code ist das so nicht ersichtlich. Wahrscheinlich hängst du den gleichen Listener an beide Dialoge, oder so.

Wie man sieht, wird DialogA von einem anderen JDialog aufgerufen, wie B von A, aber das ist denke ich mal nicht von Belang

Warum tust du denn sowas? Hört sich nicht unbedingt nach einem bewährten GUI Konzept an.

 

[UnkiDunki]

Ok, werde mal schauen... irgendwas wird sich dann wohl doch grob unterscheiden. Ggf poste ich meine Entdeckung noch mal in diesem Thread, wenn ich denn herausbekomme, wo der Fehler steckt

Warum tust du denn sowas? Hört sich nicht unbedingt nach einem bewährten GUI Konzept an.

Klär mich mal auf Habe früher nur JFrames benutzt, was hier im Forum stark kritisiert wurde, da nur ein JFrame benutzt werden sollte.
Nun habe ich auf JDialogs umgestellt, die ich zum Einen zum Datenaustausch benutze (von einem ins andere) und gleichzeitig gewährleistet ist, dass das darunterliegende Fenster solange gesperrt ist, wie das aktuelle geöffnet. Was ist daran falsch? Und wie sieht es "richtig" aus, wenn es sowas wie "richtig" überhaupt gibt. Sicherlich "besser" und das würde ich gerne erfahren
Momentan erfüllen JDialogs perfekt ihren Zweck und was ist genau daran auszusetzen? Danke für Feedback

 

[Schandro]

Ich glaube er meint damit eher das du einen JFrame hast welches einen JDialog öffnet welcher einen JDialog öffnet welcher einen JDialog öffnet. Ziemlich tiefe Schachtelung, vorallem da ja bei deinem Code alle "hinteren" Dialoge mit zugehen wenn man den Top-Dialog schließt.

Vielleicht macht das ganze aber ja Sinn in deinem speziellen Programm.

 

[Gast2]

ja wenn sie alle modal sind kommt er ja da nicht ran ...
Warum machst du nicht ein Wizard so wie bei einem Installationsprogramm mit weiter usw...?

 

[Schandro]

ja wenn sie alle modal sind kommt er ja da nicht ran ...

In seinem Code sind sie nich modal

Aber ja, z.b. ein weiterbutton was die Anzeige innerhalb des Dialoges umschaltet anstatt einen weiteren Dialog zu öffnen könnte das Problem der vielen Dialoge beheben, kommt aber drauf an wie das Programm des TO am Schluss seien soll.

 

[UnkiDunki]

Hey, ich kann euch hören

Also... es mag sein, dass das ganze ein wenig tief geht, ist aber von mir so gewollt. Kommt doch ganz auf die Komplexität des Programms an, oder nicht? Es sind glaube ich maximal 4 Ebenen...
Das ist auch nicht mehr als in jedem "normalen" Programm, z.B. "Einstellungen" -> "Erweitert" -> "Farben" etc.
Ich finde das jetzt keine soooo ungewöhnliche Struktur oder sehe ich da was nicht richtig?

Ziemlich tiefe Schachtelung, vorallem da ja bei deinem Code alle "hinteren" Dialoge mit zugehen wenn man den Top-Dialog schließt.

Bitte um Aufklärung Wie SirWayne schon sagte: An den Top-Dialog kommt man nicht dran, da dieser ja solange gesperrt ist, wie der von ihm aufgerufene Dialog geschlossen wird! Wie kommst du drauf, dass meine Dialog nicht modal wären?

 

[Gast2]

Im ersten Bsp. sind sie nicht model...
Im 2ten ja...

Also ich habe noch kein Programm gesehen, dass mehrere modale Dialoge hintereinander öffnet...

 

[UnkiDunki]

Stimmt im ersten ja... muss das jetzt noch mal alles genauer analysieren

Also ich habe noch kein Programm gesehen, dass mehrere modale Dialoge hintereinander öffnet...

Stehe ich so auf dem Schlauch Wie realisiert man denn sonst mehrer Fensterebenen, wo immer nur das aktuell geöffnete den Focus zulässt und die anderen darunter gesperrt sind? Sowas gibt es nicht? Lässt man die alle ungesperrt? Das führt doch zur Anarchie

 

[Schandro]

Lass dich besser nicht so verunsicheren von unseren Aussagen, wenn du überzeugt bist das es auf dein spezielles Programm passt dann mach es auch so. Diese Aussagen von uns sind oft, aber eben nicht immer gültig.

 

[Wildcard]

Also... es mag sein, dass das ganze ein wenig tief geht, ist aber von mir so gewollt. Kommt doch ganz auf die Komplexität des Programms an, oder nicht? Es sind glaube ich maximal 4 Ebenen...

Ich kenne kein einziges Programm das so viele Dialog Ebenen hat. Es gibt auch Dinge wie Tabs, Splitpanes mit einem Auswahlbaum links und entsprechenden Context Panels rechts usw.
Schau dich doch einfach mal in deiner IDE (Eclipse, Netbeans,...) um. Das sind naturgemäß sehr komplexe Programme die definitiv nicht so viele Dialog Ebenen brauchen.

 

[UnkiDunki]

Ok, du hast natürlich recht, dass man das bestimmt eleganter regeln lassen lässt.
Der Grund, warum das bei mir bei den Ebenen so tief ist, wird hier wohl auch auf Kopfschütteln treffen:

Ich habe ein JFrame, das einen DialogA aufruft z.B. mit einer Tabelle von Elementen. Möchte man dort ein Element hinzufügen oder editieren, wird widerum ein Dialog (B) aufgerufen, der sich um die entsprechenden Eingaben kümmert. Beim Schließen wird die Tabelle in A dann aktualisiert. Ok... Das wäre noch eine normale Tiefer, oder?
Jetzt kommen wir zu dem Punkt, der das ganze "leider" so tief macht, wie ich es momentan habe:
Ich habe einen Dialog C, der auch Elemente enthält, diese Elemente stehen im Zusammenhang mit den Elementen aus A.
Um auch von C aus Elemente aus A editieren zu können, habe ich das so gereget, dass man direkt von C A aufrufen kann, anstatt erst über das JFrame und aus A lässt sich ja B aufrufen. Das macht dann C -> möglicherweise D (Eigenschaften des Elementes) -> A -> B.
So kommt das Ganze zustande. Mit Sicherheit sind solche... ja wie nennt man sowas... Kreuz&Querverweise sicherlich kein guter Stil mhmm...

EDIT: Nichtsdestotrotz habe ich den Fehler bei meinem Code gefunden: Ich muss wie im zweiten Post "(JDialog)null" anstatt "this" übergeben, dann tritt der Fehler natürlich nicht mehr auf

 

[Wildcard]

Wäre deine Tabelle bereits im Frame, wäre nichts davon nötig, oder?

 

[UnkiDunki]

Machen wir das ganze mal ein wenig "plastischer", auch wenn wir jetzt leicht Off-Topic gehen, aber mir kann das nur recht sein:
Es geht um eine Warenwirtschaft.
Das heisst ich habe verschiedene Übersichten: "Artikel", "Kunden", "Lieferanten", etc. - Das könnte man noch direkt auf das JFrame setzen. Du denkst da an ne Realisierung mit "Tabs", oder? Alle diese Gruppen haben verschiedene Kategorien, die ich in einem JTree nebst der jeweiligen Tabelle anzeigen lasse. Zum Editieren der Kategorien öffne ich wieder ein Dialog, der mir den jeweiligen Baum nochmals abbildet, aber dieses mal mit den Buttons zum Hinzufügen, Editieren, Löschen... Im Prinzip könnte ich mir diese Ebene auch wieder sparen in dem ich die Buttons direkt im JFrame z.B. unter den Kategorienbaum setze... Ok!
Da lässt sich tatsächlich einiges sparen!
Wie sieht es aber jetzt zum Beispiel mit folgendem aus: Artikel -> Editieren... Wir befinden uns jetzt im Artikeldetailsfenster. Dort kann man jetzt für Artikel z.B. ne Einheit (kg, Liter) in ner Combobox auswählen. Bisher bin ich so verfahren, dass man durch Drücken von "+" in das Einheitenfenster kam, wo man auch wieder Hinzufügen, Editieren, Löschen konnte.
Das wäre dann Artikel -> Artikel-Details -> Einheiten -> Einheiten-Details. Das löse ich jetzt so, dass ich auch das Einheitenfenster nicht durch die Artikeldetails aufrufen lasse, sondern über das JFrame?
Würdest du oder ihr das jetzt auch so realisieren? Ich meine, das macht das ganze auf jeden Fall übersichtlicher und wenn ich eines will, dann was ordentliches fabrizieren, auch wenn es bei mir wahrscheinlich noch an vielen anderen Ecken "duster" aussieht

Vielen Dank schon mal für euer Input!

 

[Wildcard]

Du kannst deine GUI natürlich so machen wie du möchtest aber nur mal so als Anregung:
Dein Baum Links, rechts zwei Dinge: Eine JTabbedPane oben, eine Properties/Details View unten.
Du öffnest ein Element aus dem Baum per Doppelklick. Ein 'Editor' für dieses Element geht als Tab in der TabbedPane auf.
Dort musst du eventuell noch bestimmte Dinge auf einzelnen Elementen ändern. Dafür hast du die Details View. Die zeigt dir eine passende Editiermaske je nachdem welches Element du im Editor ausgewählt hast.
Wie gesagt, ich kenne deinen Vorstellungen nicht, aber es ist mal ein anderer Ansatz.

 

[UnkiDunki]

Du kannst deine GUI natürlich so machen wie du möchtest aber nur mal so als Anregung:

Klar, das weiss ich. Ich bin aber wirklich für jede Anregung dankbar Nur so kann es aufwärts gehen

Dein Baum Links, rechts zwei Dinge: Eine JTabbedPane oben, eine Properties/Details View unten.
Du öffnest ein Element aus dem Baum per Doppelklick. Ein 'Editor' für dieses Element geht als Tab in der TabbedPane auf.
Dort musst du eventuell noch bestimmte Dinge auf einzelnen Elementen ändern. Dafür hast du die Details View. Die zeigt dir eine passende Editiermaske je nachdem welches Element du im Editor ausgewählt hast.
Wie gesagt, ich kenne deinen Vorstellungen nicht, aber es ist mal ein anderer Ansatz.

Das ist auf jedenfall interessant! Du bist kein Freund von Dingen, die sich "öffnen", das ist klar
Im Prinzip "plädierst" du also dafür, dass man für eine vernünftige Übersicht bzw. Usability im Ganzen möglichst alles direkt "im Blick hat"? Also wirklich versucht, so wenig Ebenen wie möglich zu schaffen?
Und klar, ich weiss natürlich, dass das mehr oder weniger ne Geschmacksfrage ist, wobei das anhand der sich jeweils unterscheidenen Usabilities eigentlich ja "handfester" wird...
Habe wohl heute meinen Hochkommatag

 

[Wildcard]

Im Prinzip "plädierst" du also dafür, dass man für eine vernünftige Übersicht bzw. Usability im Ganzen möglichst alles direkt "im Blick hat"? Also wirklich versucht, so wenig Ebenen wie möglich zu schaffen?

Zumindest ist das die Art von Applikation die ich bevorzuge. Popups/Dialoge sind für mich Spezialfälle. Ausserhalb dem normalen Anwendungsfluss, Statusmeldungen, Fortschrittsanzeigen,... nicht jedoch der Default Way Content zu editieren.

 

[UnkiDunki]

Ok Mir gefällt ehrlich gesagt auch deine Umsetzung besser und ich werde das ganze auch dementsprechend umgestalten. Das Layout muss ich mir natürlich noch stark überlegen, aber da hast du mir schon einen sehr guten Ansatz geliefert! Sei recht herzlich bedankt! Den anderen natürlich auch für ihre Beiträge

 

[Gast2]

Für solche Sachen gibt es auch schon fertige Frameworks... Musst das Rad ja nicht neu erfinden

10 Free Docking Frameworks for Java | Java By Example | Dock

 

[UnkiDunki]

Danke für den Link, aber... neeeee... erfinden will ich das Rad nicht neu, aber selber bauen... das schon