Listener

[RealHAZZARD]

Servus.

Ich stelle immer wieder fest, dass ich im Listener nicht wirklich alles machen kann, was ich "aussen" ohne Probleme machen könnte.
Ein kleines Beispiel:
Ich möchte im ListSelectionListener einen Button disablen.
Da bekomm ich sowas:
Cannot refer to a non-final variable _button_delete inside an inner class defined in a different method

Wie benutzt Ihr denn die Listener?
Was mache ich falsch?

THX

 

[takidoso]

Hallole,
gib mal ein Code Beispiel, dann ist es einfacher und präzisier möglich zu antworten.

Takidoso

 

[schnuffie]

Innerhalb von Methoden eingebettete Klassen dürfen nur auf final-Variablen der Methode zugreifen.

Soweit die Definition. Deklariere die Button-Variable als final, dann wird's gehen.

 

[RealHAZZARD]

@takidoso:
Ein Beispiel wollte ich nicht geben, weil mir Probleme dieser und änlciher Art immer wieder unterkommen. Aber ok:

_list.addListSelectionListener(new ListSelectionListener(){
            public void valueChanged(ListSelectionEvent lse) 
            {
                _button_delete.enable(true);
}

@schnuffi:
OK. Aber was bewirk das final noch alles, ausser dass der mich dann nicht mehr anmeckert? Final sagt doch, dass die "Variable nicht ändert!?

 

[takidoso]

Ja dann wird es vermutlich gehen, ich halte es aber für keine so schöne Lösung. Wobei das sicher eine Ermessensfrage ist.
Bei Listenern, die mehr erwarten, würde ich vermutlich entwede nicht als anonyme Adpaterklassen definieren, oder einfach eine Funktion aufrufen lassen, die in ihrer einbettenden Klasse enthalten ist, und von dort aus das wesentlich tun.

Takidoso

 

[takidoso]

Ja genau, Final beduete so viel wie mach aus dem Bezeichner eine Konstante.
das dürfte bei deinen Buttons vermutlich keine große auswirkung haben, aber ich würde diesen Ansatz dennoch nicht verfolgen, es sei denn ich bin mir sicher dass ich auch in zukunft nicht vielleicht andere Buttons in den Bezeichner legen will.
machst Du ihn final so wikrt isch es möglicherweise auf Deine Initialisierung aus, soll heißen erneute Zuweisungen nach spätestens dem Konstruktor dürften vom Compiler verweigert werden.

 

[RealHAZZARD]

Das mit der Methode aufrufen, die dann ausserhalb die Arbeit übernimmt dachte ich mir auch schon, aber ich hatte eben auf weitere Lösungswege gehofft.
Das mit dem "anonyme Adapterklasse" versteh ich nicht.
Kannst du mir das vielleicht etwas näher erklären?

 

[RealHAZZARD]

zum 2. Post:
Ich will den Ansatz auch nicht unbedingt weiter verfolgen, aber mich hat eben interessiert,
was das denn so bewirkt.

 

[takidoso]

Das mit der Methode aufrufen, die dann ausserhalb die Arbeit übernimmt dachte ich mir auch schon, aber ich hatte eben auf weitere Lösungswege gehofft.
Das mit dem "anonyme Adapterklasse" versteh ich nicht.
Kannst du mir das vielleicht etwas näher erklären?

also Dein Beispiel Code ist die Syntax für anonyme Adapterklasse.
Normalerweise ist es doch so, dass wenn ich ein Objekt haben ich dazu eine Klasse schreiben oder vorliegen haben muss. Dazu gibt es 2 verschiedene syntaktische Möglichkeiten:
1. Beispiel als Listener

class EinbettendendesBla 
{
    IrgeneinGUIelement guiElement = ...

    private void ini()
    {
        guiElement.addListener(new BlablaListener());
    }

}



class BlablaListener implements Listener
{
   public void listenerMethode(Event e)
   {
        ....
   }
}

2. Beispiel als Anonyme Adapterklasse

class EinbettendendesBla 
{
    IrgeneinGUIelement guiElement = ...

    private void ini()
    {
        guiElement.addListener(new Listener()
         {
            public void listenerMethode(Event e)
            {
              ....
            }

         });
    }
}

Die Syntaxalternative der "anonymen Adapterklasse" ist im Grunde eine verkürzte Form, in der man sich keine Gedanken um einen Klassennamen macht, da aus dem Interface oder einer anderen Klasse heraus selbst eine neue Klasse gebildet wird. Der Compielr wird jedoch wie bei jeder Klasse egal ob intern oder nicht ein extra class-file erstellen. Sinn dieser Alternative ist es halt eine kürzere Schreibweise, und keine Inflationen von Klassenamen zu erleiden. Da Mensch keine Namen dafür vergibt, nennt man es halt anonymer Adapter oder anonyme Adapterklasse. (nicht zu verwechseln mit den Adapterklassen, die die methoden im vorgegebenen Interface leer implementieren um auch hier dem Programmierer schreibarbeit abzunehmen (s.MouseAdapter-Klassen).

in der Hoffnung das es verständlich war

Takidoso

 

[RealHAZZARD]

Ja. Danke. Ich vetsehe.
Aber:

Bei Listenern, die mehr erwarten, würde ich vermutlich entwede nicht als anonyme Adpaterklassen definieren, oder einfach eine Funktion aufrufen lassen, die in ihrer einbettenden Klasse enthalten ist, und von dort aus das wesentlich tun.

...selbst wenn mein Listerner nicht anonym ist, habe ich doch immernoch das Problem, dass ich solche Späße wie _button_delete.enable(true) nicht im Listener hinbekomme, oder?