Java probleempje

[Verwijderd]

Java:

public class bioApp1 extends Frame {
    public bioApp1() {
    Label test;
    
    TextField loginVeld = new TextField();
    add(loginVeld);
    loginVeld.setBounds(200, 100, 100, 20);
    TextField paswoordVeld = new TextField();
    add(paswoordVeld);
    paswoordVeld.setBounds(200, 150, 100, 20);

    final String login = loginVeld.getText();
    final String pass = paswoordVeld.getText();

    test = new Label("", Label.CENTER);
    test.setBounds(250,250,100,20);
    add(test);

    Button loginButton = new Button("Login");
    loginButton.setBounds(100, 250, 100, 20);
    add(loginButton);
    loginButton.addActionListener(
      new ActionListener()
        {
          public void actionPerformed(ActionEvent e)
            {
              if ((login.equals("a")) && (pass.equals("b")))
              test.setText("Login OK");
           }
        }
      );

  }
  //Main method
  public static void main(String[] args) {
    new bioApp1();
  }
}

het probleem zit hem in de inner class, die zegt dat Test (is een label) niet final is. Maar als ik die final maak dan kan ik die niet meer veranderen.
Maar het vreemde is in een andere programma van me, staat ook zo'n inner class en ook met een referentie naar een label en die werkt wel, zonder dat ik die label final maak.
De volgende code werkt wel

Java:

Label moveTekst;
    moveTekst = new Label("", Label.CENTER);
    moveTekst.setBounds(55, 380, 200, 20);

    knopOpvragen.addActionListener(
    new ActionListener()
      {
        public void actionPerformed(ActionEvent e)
          {
            moveTekst.setBackground(Color.white);
            moveTekst.setText("De beelden worden opgevraagd");
            paneel.setVisible(true);
            opvraag.beeldjesOpvragen();
          }
      }
    );

[ Voor 28% gewijzigd door Verwijderd op 25-04-2005 12:43 ]

[BasieP]

dit is een typisch prog vraagje, dus wat doet het in SA?

enneuh misschien kan je 90% van die boveste code weghalen, zodat wij niet zo hoeven te spitten door je code?

[Verwijderd]

Move SA->PW

[Alarmnummer]

Komt omdat de ene keer het een veld van de class is en de andere keer een variabele in een methode.

Waarschuwing:
Pas op met het gebruik van anonymous innerclasses. Je code kan er erg onleesbaar door worden. persoonlijk vervang ik meestal ze door normale innerclasses.

[Verwijderd]

Alarmnummer schreef op maandag 25 april 2005 @ 12:42:
Komt omdat de ene keer het een veld van de class is en de andere keer een variabele in een methode.

Waarschuwing:
Pas op met het gebruik van anonymous innerclasses. Je code kan er erg onleesbaar door worden. persoonlijk vervang ik meestal ze door normale innerclasses.

Nee de codes zijn het zelfde opgebouwd, heb copy paste gedaan, maar de ene is een application en andere (onderste) is een applet. Maar bij de onderste heb ik iets meer code verwijderd.

[Janoz]

Het label test is enkel als test bekend binnen de scope van de constructor van BioApp1. Zodra de constructor klaar is bestaat test niet meer. De label bestaat nog wel, maar dat komt alleen maar omdat je deze hebt toegevoegd. Dat hij ook test genoemd werd gold alleen binnen de constructor.

Waneer je die test globaal definieerd is hij beter aan te spreken. Sowieso is het dan netter om daar vervolgens getters en setters omheen te maken.

[Creepy]

Overigens, zou je via een topicreport een nieuwe topictitel willen aangeven? Zie ook *** Over topictitels in P&W - lezen voor topic openen!!! ***

[mr.inno]

Verwijderd schreef op maandag 25 april 2005 @ 12:32:

Java:

public class bioApp1 extends Frame {

    final Label test = new Label("", Label.CENTER);
    public bioApp1() {
  }

}

zo zou het moeten werken.

ow en ps : het is de bedoeling dat je je school opdrachten zelf / in groeps verband met je mede studenten maakt

[Alarmnummer]

mr.inno schreef op dinsdag 26 april 2005 @ 09:46:
[...]

zo zou het moeten werken.

Zonder zou het ook moeten werken. Closure over velden van een class is anders dan de closure bepalen van lokale variabelen. De java compiler die kijkt er op een redelijke lompe manier naar lokale variabelen en eist dat een local variable final is als je deze wilt gebruiken in een andere methode aanroep (dat heb je hier omdat je een innerclass hebt met een methode waar je de variabele ook wilt gebruiken). Hierdoor kan de compiler gewoon de waarde waar de variabele naar wijst meenemen in de andere functie (hij zal daar onder de grond stiekum wel een nieuwe variabele aanmaken met exact dezelfde naam).

Voor deze beperkte aanpak is gekozen zodat je geen 'parent' stackframes kan krijgen. Dit veroorzaakt nogal wat complexiteit met de stackframe-boekhouding.

[ Voor 13% gewijzigd door Alarmnummer op 26-04-2005 10:31 ]

[mr.inno]

je kunt hem ook gewoon niet final maken .

[Robtimus]

mr.inno schreef op dinsdag 26 april 2005 @ 11:09:
je kunt hem ook gewoon niet final maken .

Dan moet het dus wel een field worden zodat je hem kan blijven gebruiken in de inner class.

[Verwijderd]

mr.inno schreef op dinsdag 26 april 2005 @ 09:46:
[...]

ow en ps : het is de bedoeling dat je je school opdrachten zelf / in groeps verband met je mede studenten maakt

Dat weet ik, maar zelfs de leraar wist er geen raad mee
Dus ik denk ik vraag het aan de echte "profs".
Maar ik ga het ff proberen dank u.

[mr.inno]

IceManX schreef op dinsdag 26 april 2005 @ 12:49:
[...]
Dan moet het dus wel een field worden zodat je hem kan blijven gebruiken in de inner class.

je kunt het dan toch ook protected maken of zit ik er nu naast.


edit :
of anders een setlabel functie maken in je bioapp1 class.
en die dan aan roepen ....

[ Voor 16% gewijzigd door mr.inno op 26-04-2005 13:20 ]

[Alarmnummer]

mr.inno schreef op dinsdag 26 april 2005 @ 13:15:
[...]

je kunt het dan toch ook protected maken of zit ik er nu naast.

Je zit er naast. Private fields zijn voor innerclasses net zoals toegankelijk als de parent class.

[edit]
Ik snap verder niet waarom dit hele geneuzel maar blijft aanhouden. Je structuur van een class overhoop gooien om aan een referentie te komen is onzin. Post hier in een paar regels je exacte probleem en dan geven we je het antwoord zodat dit treuzel topic over is.

[ Voor 33% gewijzigd door Alarmnummer op 26-04-2005 13:18 ]

[Alarmnummer]

IceManX schreef op dinsdag 26 april 2005 @ 12:49:
[...]
Dan moet het dus wel een field worden zodat je hem kan blijven gebruiken in de inner class.

Nee.. je kan het ook meegeven als argument aan de innerclass.

[ Voor 4% gewijzigd door Alarmnummer op 26-04-2005 13:19 ]

[NMe]

Verwijderd schreef op dinsdag 26 april 2005 @ 13:02:
Dat weet ik, maar zelfs de leraar wist er geen raad mee
Dus ik denk ik vraag het aan de echte "profs".
Maar ik ga het ff proberen dank u.

Geef eerst eens aan wat je als titel wil hebben voor dit topic. Creepy kon (zo te zien ) al geen betere titel bedenken, en ik ook niet. Zie ook *** Over topictitels in P&W - lezen voor topic openen!!! ***.

[gilgames]

Het helpt als je anonieme inner classes zo klein mogelijk houdt(ze zijn niet echt lekker leesbaar). Daarom gebruik ik zelf een callback method in de top-level class.

anonieme class:

Java:

loginButton.addActionListener(
  new ActionListener() {
    public void actionPerformed(ActionEvent e) {
      loginButtonActionPerformed(e);
    }
  }
);

callback:

Java:

public void loginButtonActionPerformed(ActionEvent e) {
  if ((loginVeld.getText().equals("a")) && (paswoordVeld.getText().equals("b")))
    test.setText("Login OK");
}

[riezebosch]

Of je implementeert in je bioApp1 een ActionListener met daarbij een method ActionPerformed, en voegt bij de loginButton.addActionListener this toe.

[Robtimus]

Alarmnummer schreef op dinsdag 26 april 2005 @ 13:19:
[...]


Nee.. je kan het ook meegeven als argument aan de innerclass.

Als die niet anonymous is wel ja, anders lukt je dat niet.

[Robtimus]

riezebosch schreef op dinsdag 26 april 2005 @ 15:03:
Of je implementeert in je bioApp1 een ActionListener met daarbij een method ActionPerformed, en voegt bij de loginButton.addActionListener this toe.

Dat is een best smerige oplossing, omdat je class dan ook door andere classes kan worden gebruikt. En nog belangrijker, omdat actionPerformed public moet zijn kunnen andere classes zomaar die method aanroepen. Vaak wil je dat niet.

Verder moet die actionPerformed dan gaan kijken welke control de source is, wat niet nodig is als je a) een aparte listener gebruikt voor elke control, of b) de control meegeeft in de constructor van de listener.

Geef toe, dit soort code is niet echt overzichtelijk:

Java:

public void actionPerformed(ActionEvent e)
{
    Object o = e.getSource();
    if (o == control1)
        // code
    else if (o == control2)
        // code
    else if (o == control3)
        // code
    ....
}