Für ein Projekt habe ich eine GUI zusammengeschustert.
Konkret habe ich ein Borderlayout, welches ich mit Containern befülle. In diesen Containern verwende ich jeweils andere Layoutmanager. Rein Optisch bin ich mit dem Ganzen zufrieden.
Der Übersichtlichkeit beim Programmieren habe ich für jeden "container" eine eigene Klasse geschrieben.
Nur jetzt ist mein Problem folgendes: die ganzen Container sollen miteinander und untereinander interagieren, sprich wenn ich bei einem Container einen Button anklicke, soll im anderen Container sich was ändern.
Könnt ihr mir bitte Tips geben, wo/wie ich welche EventListener passenderweise hinschreib um das gewünschte Ergebnis zu erhalten?
Für ein Projekt habe ich eine GUI zusammengeschustert.
Konkret habe ich ein Borderlayout, welches ich mit Containern befülle. In diesen Containern verwende ich jeweils andere Layoutmanager. Rein Optisch bin ich mit dem Ganzen zufrieden.
Der Übersichtlichkeit beim Programmieren habe ich für jeden "container" eine eigene Klasse geschrieben.
Nur jetzt ist mein Problem folgendes: die ganzen Container sollen miteinander und untereinander interagieren, sprich wenn ich bei einem Container einen Button anklicke, soll im anderen Container sich was ändern.
Könnt ihr mir bitte Tips geben, wo/wie ich welche EventListener passenderweise hinschreib um das gewünschte Ergebnis zu erhalten?
... die Events willst du wohl maßgeschneidert für deine Aufgabe. Also mußt du selbst Events und Listener bereitstellen. Z.B.
Code:
package exi.Terra1;
//zu senden wenn via Doppelklick eine Basis gewählt wurde
public class Event_Selektiert extends java.util.EventObject {
private int Nr=-1;
public Event_Selektiert(myFarbPanel source, int ein){
super(source);
Nr = ein;
}
public int getNr() {return Nr;}
}
Code:
package exi.Terra1;
public interface Listener_Selektiert extends java.util.EventListener {
public void Selektiert_ActionChoosen(Event_Selektiert evt);
}
nun müssen aber auch beide Programmteile wissen das sie Events austauschen sollen. Dafür muß der Sender passende add-Methoden beritstellen:
Code:
protected void fireEvent_Selektiert(int ein){
Object[] listeners = listenerList.getListenerList();
Event_Selektiert event = null;
for (int i=listeners.length-2; i>=0; i-=2)
if (listeners[i]== Listener_Selektiert.class){
if (event == null)
event = new Event_Selektiert(this, ein);
((Listener_Selektiert) listeners[i+1]).Selektiert_ActionChoosen(event);
}
}
public void addListener_Selektiert(Listener_Selektiert aListener){
listenerList.add(Listener_Selektiert.class, aListener);}
public void removeListener_Selektiert(Listener_Selektiert aListener){
listenerList.remove(Listener_Selektiert.class, aListener);}
Und der Empfänger muß gesagt bekommen, daß er zuhören soll und was ggf. zu tun sei. Das mache ich gewohntheitsmäßig dort wo ich alle andere Aktionen erkläre.
Code:
myPanel.addListener_Selektiert(new Listener_Selektiert() {
public void Selektiert_ActionChoosen(Event_Selektiert e){
int puffer = e.getNr();
for (int i=0; i<PanelListe.size(); i++)
if (i!=puffer) ((myFarbPanel)PanelListe.get(i)).setSelektiert(false);
}});
Bei der Bezeichnung ist man relativ frei. Aber aus Erfahrung habe ich gelernt ein stures System einzuhalten. Schlüsselbegrifft wie 'fireEvent', 'addListener' behalte ich bei. Und dann füge ich meine Bezeichnung mit einem Unterstrich dazu.
und beinahe hätte ich es vergessen ;-) Natürlcih muß der Sender auch entscheiden wann der Event geschickt werden soll. Das geht mit einer direkten Anweisung wo du fireEvent befiehlst. Z.b. innerhalt eines ActionListeners:
Ausführliche Antworten sind zwar manchmal ganz schön, aber... in diesem Fall wäre IMHO als erste Antwort ein "Das kommt darauf an...." abgebrachter gewesen :wink:
Es kommt darauf an....
- welche der Components welche andere Component kennt
- welche Aktionen durchgeführt werden sollen
- ob es ein Datenmodell gibt
-....
(Es macht z.B. nur bedingt Sinn (nicht "keinen Sinn", aber 'nur bedingt Sinn'!!!) eine Component mit einem eigenen, auf Basis von EventObject und EventListener zusammengstrickten Klasse über etwas zu informieren, was man ihr (weil sie evtl. schon bekannt ist) auch direkt über eine Methode sagen könnte...)
