Weitere Parameter in die paintComponent()-Methode übergeben?

[Wesloth]

Hab zurzeit nur folgendes Grundgerüst:

package haupt;

import java.awt.*;
import javax.swing.*;

public class Grafik extends JPanel
{ 
	@Override 
	protected void paintComponent( Graphics g ) 
	{ 
		g.drawLine(0,0,100,100);
	};

	public static void main( String[] args ) 
	{ 
		JFrame f = new JFrame(); 
		f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 
		new Grafik();
		f.setSize(200, 200); 
		f.setVisible(true); 
	};
};

Jetzt würde ich der paintComponent-Methode gerne ein Array als Parameter übergeben, jedoch erhalte ich immer die Fehlermeldung:
The method paintComponent( Graphics, int[]) of type Grafik must override or implement a supertype method

Kann man damit also nur hartgecoded arbeiten :shock:
Oder gibts da Tricks mit denen ich da doch ein bisschen Variabilität rein bringen kann.

btw. Es gibt im Kopf der Klasse Grafik noch folgenden Hinweis:
The serializable class Grafik does not declare a static final serialVersionUID field of type long
Was?

 

[Tobias]

Ein Methode, die die Annotation @Override trägt, muß auch eine Eltern-Methode überschreiben. In JComponent gibt es aber keine Methode paintComponent(Graphics, int[]).

Die serialVersion UID kannst du dir von Eclipse generieren lassen oder eben selbst hinschreiben: public static final long serialVersionUID = 123; // Der Wert ist annähernd völlig egal. Man kann diese Warnung aber auch in den Projekteigenschaften abschalten.

 

[Wesloth]

Klar, aber wenn ich das @Override wegnehme wird auch nicht gemalt.

 

[Tobias]

Warum sollte der Swing-Painting-Mechanismus eine ihm völlig unbekannte Methode aufrufen, von der er überhaupt nicht weiß, welche Parameter er wie übergeben soll? Das hat mit dem @Override gar nichts zu tun. Swing ruft die paintComponent(Graphics)-Methode auf uns sonst gar nichts. Ist ihm herzlich egal wie viele gleichnamige andere Methoden du sonst noch hast, entscheidend ist die Signatur.

 

[André Uhres]

Wir können uns eine neue Methode machen, die dem Objekt das Array übergeben kann.
Beispiel:

package haupt;
/*
* Grafik.java
*/
import java.awt.*;
import javax.swing.*;
public class Grafik extends JPanel {
    private int[] values;
    @Override
    protected void paintComponent(final Graphics g) {
        super.paintComponent(g);
        for (int y : values) {
            g.drawLine(0, y, 100, 100);
        }
    }
    public void setValues(final int... values) {
        this.values = values;
    }
    public static void main(final String[] args) {
        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                JFrame f = new JFrame("Grafik Demo");
                f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                Grafik grafik = new Grafik();
                grafik.setValues(10, 20, 30, 40, 50, 60, 70, 80, 90, 100);
                f.add(grafik);
                f.setSize(200, 200);
                f.setLocationRelativeTo(null);
                f.setVisible(true);
            }
        };
        SwingUtilities.invokeLater(runnable);
    }
}

 

[Wesloth]

Vielen Dank 😀
Solche Tricks hab ich gemeint.
Nur habe ich mal dieses runnable raus genommen:

    public static void main(final String[] args) {
        //Runnable runnable = new Runnable() {
          //  @Override
          //  public void run() {
                JFrame f = new JFrame("Grafik Demo");
                f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                Grafik grafik = new Grafik();
                grafik.setValues(10, 20, 30, 40, 50, 60, 70, 80, 90, 100,200);
                f.add(grafik);
                f.setSize(200, 200);
                f.setLocationRelativeTo(null);
                f.setVisible(true);
            //};
        //};
        //SwingUtilities.invokeLater(runnable);
    };

Oder ist das irgendwie wichtig, weil es funktioniert auch so genauso gut wie vorher.

 

[Tobias]

Ja, aber nicht zwangsweise immer. Irgendwann wird dein Programm möglicherweise mal komisch kaputt gehen. EDT und Threadsicherheit von Swing sind die Schlagworte für das Studium eines beliebigen Lehrbuchs dazu.

 

[André Uhres]

Initial Threads und Event Dispatch Thread


Initial Threads

In Swing Programmen haben die Initial Threads nicht viel zu tun. Ihre Hauptaufgabe ist
ein Runnable Objekt anzulegen, das die GUI initialisiert, und dieses Objekt zur Ausführung
auf den Event Dispatch Thread zu schicken.
Ein Initial Thread schickt den GUI Initialisierungsantrag auf den Event Dispatch Thread mit dem Aufruf von
javax.swing.SwingUtilities.invokeLater oder javax.swing.SwingUtilities.invokeAndWait.
Lies mehr dazu...

Event Dispatch Thread

Einige Swing Komponentenmethoden sind in der API Spezifikation als "thread safe" gekennzeichnet;
solche Methoden können von irgendeinem Thread sicher aufgerufen werden.
Alle anderen Swing Komponentenmethoden müssen vom Event Dispatch Thread aus aufgerufen werden.
Programme, die diese Regel ignorieren, könnten zwar meistens korrekt laufen,
sind aber unvorhersehbaren Fehlern unterworfen, die schwer nachvollziehbar sind.
Lies mehr dazu...