Componenten auf einer JDesktopPane überprüfen

[MadMetzger]

Hallo zusammen!

In meinem Studium bin ich gerade mit einem Projekt beschäftigt. Wir sollen eine Anwendung zur Simulation von Stellen-Transitions-Netzen(PetriNetze) auf Basis von Java erstellen.

Hierbei bin ich auf eine Frage gestossen: Ich kann ein Netz mehrfach simulieren und solange die Anwendung offen ist, bleiben die Simulationen erhalten(Persistenz war nicht Bestandteil der Aufgabe). Bestehende Simulationen eines Netzes werden mir in meinem Hauptfenster innerhalb einer JList angezeigt. Nach gewisser Anzahl von Simulationsfenstern, kann es sein, dass man den Überblick verliert. In dem Fall möchte ich über einen Doppelklick auf den Eintrag in der Liste mir das Fenster wieder holen. Dazu muss ich für jedes Fenster(ein JInternalFrame), dass in der JDesktopPane abgelegt wurde, überprüfen, ob es eine Referenz auf diese markierte Simulation hat. Dazu lasse ich mir von der Pane alle Components (mit pane.components() )zurückgeben, jedoch ist mir bei dem Array, dass da zurückkommt nicht ganz klar, wie ich darüber iterieren kann. Wenn ich mit

• anfange, bekomme ich schon eine ArrayIndexOutOfBoundsException um die Ohren geknallt... Aber ich bin mir sicher(habe mit Debugger geschaut und habe das Fenster auch dort gesehen), dass dort ein passendes Fenster vorhanden ist.  Oder wähle ich den falschen Ansatz. Stehe atm ein bißchen auf dem Schlauch in der Geschichte...

Anbei ein Schirmschuss zur Verdeutlichung...

[Ralf_M_Petter]

Mir kommt der Ansatz zwar etwas kompliziert vor, du könntest für die Liste auch ein eigenes Datenmodell verwenden, wo dann die Referenz auf den Internalframe abgelegt ist. Aber poste doch mal die Stelle im Source wo der Fehler passiert mit der Angabe eventuell des StackFrames. Dann werden wir sicher eine Lösung finden.

Grüße

Ralf

[MadMetzger]

Du meinst im Prinzip eine Wrapperklasse um die Simulation herum, die eine Referenz auf das Fenster hat? Das klingt sogar sehr gut... werde ich heute Mittag mal ausprobieren...

[MadMetzger]

Tja, klappt ja an sich ganz gut mit der Wrapperklasse, ich kriege dann auch das passende Fenster i Zugriff, nur weiß ich nie genau, was ich mit dem Fenster machen soll. Es kann geschlossen worden sein, oder minimiert, oder auch nur hinter anderen versteckt. Welche Methode muss ich von den JInternalFrames aufrufen, damit ich das Fenster in jedem Fall kriege? Im Moment sage ich einfach nur setVisible(true) und es geht zwar aber irgendwie klappt es manchmal(?) nur auf den zweiten Klick und wenn es minimiert war, kommt zwar das Fenster in den Vordergrund aber der minimierte "Rest" bleibt bestehen... 

[flaite]

Ralfs Ansatz würde ich erstmal zustimmen. Das mit dem ListModel.
Warum Wrapperklasse? Implementierst du http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/ListModel.html ?
JInternalFrame für User schliessbar machen und in der Liste lassen hört sich auch irgendwie gefährlich an.
JInternalFrame hat btw. sich vielversprechend anhöhrende Methoden wie toFront() und show().
Den Status kannst du offenbar mit so Methoden wie isIconified (in JInternalFrame) abfragen. Hab allerdings noch nie JInternalFrame benutzt. Aus meiner Erfahrung mit Swing würd ich sagen, dass du irgendwann weisst wie.

[MadMetzger]

Für den Moment habe ich das minimieren verboten. Ich habe es nicht hinbekommen bzw. habe aus Zeitgründen erstmal diesen Weg gewählt... Dann kann ich das Fenster schließen und bekomme die Simulation wieder über die Liste per Doppelklick geöffnet.

Ich habe irgendwie nicht die Unterschiede zwischen show() und setVisible(true)  und anderen Methoden verstanden... die waren nicht so klar beschrieben in der API-Doku... Daher dieser Weg.

Du hast insofern recht, dass man Swing am ehesten beim Benutzen lernt. Vor diesem Projekt wusste ich gerade mal, wozu man Swing gebrauchen kann...

Trotzdem erstmal ein Dankeschön an alle! Werde mich jetzt anderen Problemen dieser Anwendung zuwenden, bzw. fürs erste schlafen gehen und PetriNetze PetriNetze sein lassen...

Gute Nacht!

[Ralf_M_Petter]

Mad metzger du verwendest aber keine Methoden von ausserhalb des Event Handler Threads. Gerade wenn in Swing Probleme auftreten, die machmal da sind und dann funktioniert wieder alles einwandfrei, sprechen dafür, dass da nicht sauber gearbeitet wird. Wie gesagt, bei Swing vor allem in den neueren Versionen darf nur von Event Handler Thread aus auf Swing Objekte zugegriffen werden. Wenn du das Bedürfnis hast, von anderen Threads auf Swing zuzugreifen musst du immer invokeLater verwenden.

Grüße

Ralf

[flaite]

Ziemlich allgemeines Gewäsch, aber sehr wahr:
Sobald du mit etwas komplexen und für dich unbekannten wie Swing unter Zeitdruck arbeitest, wirst du alle Prinzipien über sauberes Design über Bord werfen und in einer Soße mit größer werdenden Klumpen enden (engl: un-maintainable code). 
Die Frage geht ja nicht über Petri-Netze, sondern über - sagen wir - "Fenster-Management", d.h. wo hälst du die Referenzen der JInternalFrames und wie bringst du sie in den gewünschten state.

Ich würd sowas in einer Klasse PresentationModel halten, die völlig unabhängig von JFrame oder sonstigen komplexen Swing-Klassen ist.
Du kannst anfangen, dir anzuschauen wie andere openSource Projekte Fenster-Management steuern. Oder Bücher kopieren. Wobei sich die meisten Swing Bücher sich mit den zahlreichen Swing-Klassen beschäftigen und weniger mit dem allgemeinen Design einer Desktop Anwendung auseinandersetzen. Eine Ausnahme ist das hier: http://www.sourcebeat.com/TitleAction.do?id=10

zu invokeLater:
Ich habs gerade wieder selber in meinem Webservices-Projekt für HELP gemerkt: Threading Issues können komplex werden. Es gibt Alternativen. Das ist ziemlich gut für das allgemeine Verständnis: http://www.javalobby.org/members-only/eps/galbraith-swing-2/?source=archives

[MadMetzger]

Aufgrund von Zeitdruck ist mir das im Moment nicht möglich solche Dinge noch zu implementieren... Leider hat ein Tag nur 24 Stunden und ein paar Klausuren muss ich ab morgen auch noch schreiben.

Der Hinweis auf eine Klasse PresentationModel klingt recht gut, bei mehr Zeit würde ich mich damit auch noch einmal auseinandersetzen...

hier mal ein Codebeispiel, in dem ich die Fenster aufrufe:

Code

private void getAendernButtonAction(){
        NetChangingWindow netChangingWindow = (NetChangingWindow) this.uebersichtList.getSelectedValue();
        if (netChangingWindow!=null){
            Aenderungsfenster af = this.controller.editNet(netChangingWindow);
            if(!this.desktopPaneHasWindow(af))this.hauptfensterDesktopPane.add(af);
            af.setVisible(true);
            af.toFront();
        }else{
            Runnable r = new StatusZeilenHandler(Constants.MESSAGE_NO_NET_FOR_DESIGNING_SELECTED, this.getStatusZeilenTextField());
            new Thread(r).start();
        }
        
    }

NetChangingWindow ist meine Wrapperklasse, die mir eine Referenz auf mein Netz und das Änderungsfenster bietet.

Wie würde ich denn bei einem minimiertem Fenster vorgehen? isIconified abfragen und dann?

[flaite]

Aufgrund von Zeitdruck ist mir das im Moment nicht möglich solche Dinge noch zu implementieren...

Gerade in der Uni ist es oft schlau, Dinge lieber ein bischen schneller zu machen, auch wenn die Qualität drunter leidet.
Hört sich komisch an, ist aber leider so.
Hab mal einen Fanatiker als Freund, der am Ende für 1-Monats Hausarbeiten 10 Monate brauchte. Die waren dann auch wirklich gut. Der Preis an Zeit war aber trotzdem nicht vertretbar.
Ich kapiere diesen Teil überhaupt nicht:

Code

 Runnable r = new StatusZeilenHandler(Constants.MESSAGE_NO_NET_FOR_DESIGNING_SELECTED, this.getStatusZeilenTextField());
            new Thread(r).start();

Sieht für mich nach überkomplexer Patternities aus?

Ich habs nicht ausprobiert, aber so die Art

Code

else {
   SwingUtilities.invokeLater(new Runnable() {
public void run() {    getStatusZeilenTextField()).setText(Constants.MESSAGE_NO_NET_FOR_DESIGNING_SELECTED);
}
}); 
} // end if

[Ralf_M_Petter]

Hallo MadMetzger!

Ist mir zwar jetzt etwas unklar, warum du einen neuen Thread machst. Aber genau in diesem neuen Thread darfst du nicht auf Swing Klassen zugreifen, da du ja dann nicht mehr im Event Handler Thread bist.

Grüße

Ralf

[flaite]

Aus dem Kopf:
1. Du packst Operationen in einen neuen Thread, wenn die Operation relativ viel Ressourcen (= Zeit) benötigt (z.B. ein RDBMS call). Sonst friert nämlich die Gui ein. In dem code-snippet, das wir hier diskutieren, brauchst du das gar nicht.
2. Wenn du einen neuen Thread benutzen solltest (wg. 1), dann sollte man das nur über SwingUtilities.invokeLater() machen.
3. Um das ganze Thread-Management Zeugs einfacher zu machen, gibt es von Sun die Klasse SwingWorker (suche auf Java.net). Ausserdem noch ein paar openSource Projekte, die aber weitgehend in dem JavaLobby Link erklärt werden. 

[MadMetzger]

Also den neuen Thread mache ich nur auf, um in einer Statuszeile untem im Fenster die von der gefangenen Exception mitgelieferte Message auszugeben und weiter arbeiten zu können. Also wenn ich Threadmäßig was an der GUI machen will, sollte ich mit SwingUtilities.InvokeLater arbeiten?

[flaite]

Die Aktion benötigt nicht viele Ressourcen.
Du brauchst das überhaupt nicht in einen neuen Thread tun.
Neuer Thread nur, wenn der code wirklich viele Ressourcen benötigt (Kandidaten: Calls gegen Lotus Notes/RDBMS/Filesystem/ Webservices)

[Ralf_M_Petter]

Ja wie schon mehrmals gesagt, du darfst von anderen Threads als der Event Handler Thread Swing Objekte nicht verändern. Falls du in einem anderen Thread bist, musst du über invokeLater die Änderungen an den Swing Objekten machen. Normalerweise schaut die Aktion so aus.

Benutzer klickt einen Button.
Der Event Handler Code des Buttons muß eine länger dauernde Operation durchführen, deshalb startet er einen neuen Thread der z.B. Daten aus einer SQL Datenbank ausliest. In der Zwischenzeit werden neue Ereignisse in der Gui ausgeführt. Das heisst, dass Fenster reagiert auf den Benutzer. Wenn der neue Thread fertig ist, muß er mit invokeLater wieder Code starten, der die Ergebnisse z.B. an das Tablemodell einer JTable übergibt.

Grüße

Ralf

[MadMetzger]

^^Sie verbraucht nicht viele Ressoucen, aber die Meldung soll angezeigt werden und nach einer festzulegenden Zeit wieder verschwinden. Und wenn ich das direkt in diesem Thread gemacht hätte, dann wäre nach meinem Verständnis die GUI blockiert. Kann mich aber auch täuschen...

[Ralf_M_Petter]

Du täuscht dich nicht, das ist völlig richtig. Du musst in dem Thread der eine Zeiteinheit wartet  2 mal invokeLater verwenden einmal um die Meldung auszugeben und einmal nach Ablauf der Wartefrist um die Meldung zu löschen. Aber Vorsicht. Während die Meldung angezeigt wird, kann schon wieder eine neue Meldung kommen. Hier solltest du dann Vorsorge treffen, dass du diese neue Meldung nicht zu früh löscht. Ausserdem würde ich hier mit einem vorgeladenen Thread arbeiten und nicht jedesmal einen neuen gernerieren, da Threadgeneration je nach Betriebssystem auch eine aufwendige Operation ist.

Grüße

Ralf

[flaite]

Wenn dieses "Fehlermeldung geht automatisch nach einer gewissen Zeit weg"-Feature nicht explizit in der Aufgabenstellung stand, würde ich es sofort rausnehmen. Mit sowas handelst du dir sonst noch Minuspunkte ein.
Thread Management ist k.o.m.p.l.e.x.
Hier wird das ein bischen angesprochen:
http://weblogs.java.net/blog/javaben/archive/2005/04/index.html
SwingWorker, Foxtrott und ähnliche Ansätze helfen, die Sachen einfacher zu machen (glaub ich).

[Ralf_M_Petter]

Kann Axel nicht zustimmen. Auf der Uni will man ja was lernen und gerade diese Aufgabenstellung ist ein Superbeispiel um komplexeres Threadmanagement zu lernen. Heute sollte jeder Java Entwickler Threads perfekt beherrschen, da das aufgrund der Prozessorentwicklung extrem wichtig wird. In Zukunft werden die grossen Performanceschübe wahrscheinlich nur noch von Multi Cores kommen und die kann man halt nur ausnutzen wenn man auch Multithreading behrerrscht.

Grüße

Ralf

[flaite]

und gerade diese Aufgabenstellung ist ein Superbeispiel um komplexeres Threadmanagement zu lernen.

Ralf,

wir kennen die Aufgabenstellung nicht. Ich weiss nur, dass Dozenten extrem negativ reagieren, wenn man etwas schlecht einbaut das gar nicht gefragt war.
Wenn das "Nachricht verschwindet automatisch"-Feature nicht gefragt war: Ein modaler Dialog und ein "Ok, schliessen" Button tut es auch.
Nix gegen Lernen. Aber bei Dingen, die von anderen bewertet werden, sollte man sich 2x Fragen, was überhaupt gefordert war.

Heute sollte jeder Java Entwickler Threads perfekt beherrschen, da das aufgrund der Prozessorentwicklung extrem wichtig wird. In Zukunft werden die grossen Performanceschübe wahrscheinlich nur noch von Multi Cores kommen und die kann man halt nur ausnutzen wenn man auch Multithreading behrerrscht.

Wie viele Java Programmierer beherrschen Threads wirklich? Laut Bruce Eckel waren vor Java 5.0 viele Java Thread Dinge buggy (z.B. volatile keyword). Als J2EE-Entwickler hat man sowieso nur sehr eingeschränkt mit Threads zu tun. Die Requests kommen treffen zwar multithreaded auf die Komponenten, jedoch muss man praktisch nie selbst neue Threads starten.

Ich glaub die größten von Programmierer verursachten Unfälle entstehen dadurch, dass Leute ihr eigenes vereinfachtes innere Bild einer komplexen Sache (Threads) mit der Wahrheit verwechseln.
Ich beschäftige mich btw. selbst mit Threads, halte es aber für komplex. Und ich denke es geht einer Menge Java-Programmierern so. Bruce Eckel findet es auffällig, dass die in Java 5.0 völlig neuen Threading Geschichten kaum diskutiert werden. Eine mögliche Erklärung ist, dass viele Java-Programmierer lieber darauf verzichten Thread-Gurus zu werden. 
In der Aufgabenstellung von Markus gehts nicht primär um Threading. Und wenn er nicht so die Erfahrung damit hat, fehlt vielleicht der Fokus, um es richtig zu machen. Dann ist es besser, Threading auf eine längerfristige "needs-work"-Liste zu packen und jetzt erstmal - wenn möglich - Abstand halten. 
Threads ist auf jeden Fall ein interessantes Thema, über das man auch eine Menge andere Dinge verstehen kann.

Gruß Axel