Swing Suche Listener für beliebige Änderung an GUI Items/Controls

[andreT]

Hallo Forum erstmal

ich suche nach einem Listener in der API (JDK7) der sich problemlos an sämtliche gängige GUI Items/Controls (JTextField/JRadioButton/...) adden lässt.
Hintergrund : Ich möchte mitbekommen ob sich an dem Item irgendwas geändert hat z.B. Wert wurde geändert vllt. auch auf den Ursprungswert ... was auch immer .... das wäre egal! Ich suche halt nur einen Listener(Typ) der auf gängige Swing-Items hört und Änderungen mitbekommt. Eigentlich geht's nur darum einen "Übernehmen" Button zu enablen wenn ich an einem GUI Item sozu. "rumgefummelt" habe.
ChangeListener und DocumentListener hab ich mal probiert, kann ich aber nicht an jedes Control adden. Ich möchte nun auch nicht für jeden Control-Typ einen eigenen Listener basteln!

Vllt. seh ich den Wald vor lauter JTrees nich ... aber im Moment komm ich da nicht recht weiter.

Hat jemand 'n Tipp?

Gruß
andre

 

[vanny]

Da die Listener Interfaces sind, kannst du dir ja eine eigene Listenerklasse schreiben, die all die Interfaces implementiert, die du benötigst.
Den "einer für alle" Listener wirst du wohl nicht einfach so finden.

Gruß Vanny

//Edit: Wobei ich deinen Ansatz sehr unschön finde.
Schöner ist es dann doch, eine Methode für das enable des Buttons zu schreiben und den jeweiligen Components den für sie spezifischen Listenertyp zu adden.
Diese greifen dann alle auf die Methode zu und gut is.(Zumal die Components ohne Listener ja eh recht sinnfrei sind )

 

[SlaterB]

wenn alle relevanten Aktionen nicht nur automatische GUI-Änderungen betreffen, was immer das sein mag,
sondern bereits jetzt jeweils einer von deinen individuellen Listener beteiligt ist,
dann wäre es vielleicht besser, bei all diesen Listener anzusetzen statt überall einen zweiten Weg einzuschlagen

alle Listener könnten beispielsweise von Basisklassen erben:

abstract class BaseListener {

   void standard() {
      // logge Event
      // registiere irgendwo Änderung an Seite ... 
   }

}


abstract class BaseActionListener extends BaseListener  implements ActionListener {

 final actionPerformed() {
    standard();
    action();
  }

  abstract void action(); 
}

eine solche Struktur kann auch andere Vorteile haben, z.B. das Loggen, z.B. eine kürzere Methode action() ohne das lästige oft unnötige ActionEvent als Parameter,
es könnte ein zweiter BaseActionListener geschrieben werden der gleich einen Thread für eine dann zu implementierende run-Methode startet,
falls man öfters aus Listenern nebenläufige Aktionen starten muss, usw.

 

[andreT]

Da die Listener Interfaces sind, kannst du dir ja eine eigene Listenerklasse schreiben, die all die Interfaces implementiert, die du benötigst.
Den "einer für alle" Listener wirst du wohl nicht einfach so finden.

Ja eben das möchte ich ja vermeiden! Ich hatte halt die Hoffnung das Swing sich da seit 1.2~1999 endlich mal etwas weiterentwickelt hätte und da jetzt mal was cleveres bereithält ... aber offensichtlich haben die es mit der Weiterentwicklung der API bzgl. Desktop Anwendungen (siehe DnD, Performance etc. nach wie vor!) wohl aufgegeben.

//Edit: Wobei ich deinen Ansatz sehr unschön finde.
Schöner ist es dann doch, eine Methode für das enable des Buttons zu schreiben und den jeweiligen Components den für sie spezifischen Listenertyp zu adden.
Diese greifen dann alle auf die Methode zu und gut is.

Ja nee iss klar! Das hat nichts mit Schönheit zu tun, sondern ist ja nur die logische Konsequenz! :toll:

Hat vllt. jemand noch einen Geheimtipp??

Gruß
Andre

 

[andreT]

wenn alle relevanten Aktionen nicht nur automatische GUI-Änderungen betreffen, was immer das sein mag,
sondern bereits jetzt jeweils einer von deinen individuellen Listener beteiligt ist,
dann wäre es vielleicht besser, bei all diesen Listener anzusetzen statt überall einen zweiten Weg einzuschlagen

alle Listener könnten beispielsweise von Basisklassen erben:

abstract class BaseListener {

   void standard() {
      // logge Event
      // registiere irgendwo Änderung an Seite ... 
   }

}


abstract class BaseActionListener extends BaseListener  implements ActionListener {

 final actionPerformed() {
    standard();
    action();
  }

  abstract void action(); 
}

eine solche Struktur kann auch andere Vorteile haben, z.B. das Loggen, z.B. eine kürzere Methode action() ohne das lästige oft unnötige ActionEvent als Parameter,
es könnte ein zweiter BaseActionListener geschrieben werden der gleich einen Thread für eine dann zu implementierende run-Methode startet,
falls man öfters aus Listenern nebenläufige Aktionen starten muss, usw.

Solche Vererbungsketten hatte ich auch schon im Sinn, aber ich habe da wirklich nur ganz trivial ca. 25 Controls (JtextField, RadioButton(Group), JComboBox) und wollte nur "stumpf" einen Button enablen wenn jemand an einem Control "rumgeklickt" hat. Ganz einfach und ohne große Prüfungen ob z.B. wirklich was geändert wurde u.ä.. Ich hatte da halt so eine Hoffnung nach 10 Jahren Swing-Abstinenz da was einfaches zu finden ... hmmm ...
Sieht wohl so aus als müsste man da nach wie vor auf low-level Ebene ran :autsch:

 

[SlaterB]

das hier gibts anscheinend noch:
AWTEventListener (Java Platform SE 6)
allerdings nicht unbedingt auf bestimmte Komponenten eingeschränkt,
vielleicht kann man Source abfragen und mit allen fraglichen Komponenten, in eine Datenstruktor eingefügt, vergleichen

 

[andreT]

das hier gibts anscheinend noch:
AWTEventListener (Java Platform SE 6)
allerdings nicht unbedingt auf bestimmte Komponenten eingeschränkt,
vielleicht kann man Source abfragen und mit allen fraglichen Komponenten, in eine Datenstruktor eingefügt, vergleichen

Sieht spannend aus. Werd ich mal einbauen und auf die entsprechenden Controls casten bzw. entsprechend reagieren.

Im Augenblick geht die Anwendung nicht da ich z.Zt. vergeblich versuche das Eclipse Projekt nun als jar-Archiv mit bat-Datei incl. der notwendigen Libraries zum Laufen zu bringen. Immer wieder ein Riesenspass wenn man die letzten Jahre immer nur mit WSAD/RSA o.ä. "fertigen Umgebungen" unterwegs war

Wenn die Anwendung wieder läuft und ich das eingebaut habe melde ich mich nochmal.
Aber schonmal vielen Dank soweit!

 

[vanny]

... aber offensichtlich haben die es mit der Weiterentwicklung der API bzgl. Desktop Anwendungen (siehe DnD, Performance etc. nach wie vor!) wohl aufgegeben.

Ich würde das jetzt nicht so hart ausdrücken, es tut sich ja doch einiges:autsch:

Vielleicht schreibst du die Sunjungs mal an und wünscht dir einen SomeThingHappendListener

 

[andreT]

Ich würde das jetzt nicht so hart ausdrücken, es tut sich ja doch einiges:autsch:

Vielleicht schreibst du die Sunjungs mal an und wünscht dir einen SomeThingHappendListener

Die wollten schon mein retry-Befehl nicht umsetzen ... also :

try {
   ...				
} catch (Exception e) {
   if(...) {
     retry;
   }				
}