Swing JFrame neuzeichnen - bleibt grau

[Sleepwalker]

Hallo,

ich habe seit geraumer Zeit ein Problem, das ich nicht weg bekomme (Java 1.5)
Folgendes: Mein Programm "durchläuft" nach dem Start verschiedene JFrames, bei denen der Benutzer Eingaben machen muss. Zwischen den JFrames soll immer ein Fortschrittsbalken angezeigt werden, bis dann das nächste JFrame auftaucht. Das Ganze erfolgt aus einer einzigen Steuerklasse heraus, von der der Status des Balkens immer per Methodenaufruf aktualisiert wird. Also:
1. JFrame-Ladebalken bis zur ersten Eingabemaske - OK
2. Maske erscheint, Benutzer stellt Dinge ein, Maske wird geschlossen - OK
3. JFrame-Ladebalken bis zur nächsten Eingabemaske - FAIL
4. Maske erscheint, Benutzer stellt Dinge ein, Maske wird geschlossen - OK
5. JFrame-Ladebalken bis zur nächsten Eingabemaske - FAIL
usw.

Das klappt aber nur 100%ig beim ersten Ladebalken. Der Ladebalken ansich ist auch ein JFrame, welches ich zwischenzeitig nur mit "setVisible(false)" unsichtbar mache und später wieder erscheinen lasse. Leider bleiben ab Schritt 3 immer alle Fortschrittsbalken komplett grau. Ohne Inhalt. Manchmal kommt der Inhalt dann nach 20 Sekunden oder so, aber das ist definitiv zu spät für einen ungeduldigen Benutzer, der nicht weiß, was passiert.
Es hilft kein repaint() und kein paintImmediately(). Letzteres verschafft mir sogar Grafikfehler. Dabei ist dann der Inhalt des Ladebalkens verschoben oder doppelt vorhanden o.ä..

Eine etwas umständliche Beschreibung, sorry
Gibt es da irgendwelche Lösungsansätze, die ich übersehe?
Vielen Dank schon einmal im Voraus.

Gruß,

Tobias

 

[Michael...]

Gibt es da irgendwelche Lösungsansätze, die ich übersehe?

Dein Vorgehen mit mehreren JFrames usw. hört sich nicht gerade schön an und ich kann mir vorstellen, dass sowas recht fehleranfällig ist.
Ich würde mir überlegen, ob nicht ein JFrame reicht und man zwischen den verschiedenen Inhalten per CardLayout wechselt.
Ansonsten kann das Problem mehrere Ursachen haben, die ohne Code schwer zu ermitteln sind. z.B. könnten blockierende oder längerwierige Prozesse auf dem EDT laufen und so das Zeichnen des GUIs verhindern, oder vielleicht liegts einfach nur am Aufbau des GUI, oder am Vorgehen beim aus und einblenden oder...

 

[Sleepwalker]

Danke für den Hinweis mit dem CardLayout. Klingt ansich sehr schön, nur leider variieren je nach Benutzereinstellungen die Größen und Inhalte der Masken. Von daher wäre das auch nicht ganz sauber, wenn ich da gerade richtig überflogen habe.
Dachte, dass mein Problem vllt. irgendwie bekannt ist.

Wenn es hilft, poste ich gerne den nötigen Code, das wird aber heute nichts mehr.

 

[Sleepwalker]

Moin,

hier der ausgedünnte, relevante Code:

Controller:

public final class Controller {
    public Controller (...) {
        ...
        oPB = new ProgressBar();
        oPB.setProgress("Status 1", 0);
        oPB.activate();
        // Hier funktioniert die "ProgressBar"
        login();
    }

    private void login() {
        oPB.setProgress("Status 2", 20);
        ...
        oPB.setProgress("Status 3", 50);
        ...
        start();
    }

    private void start() {
        ...
        oPB.setProgress("Status x", 75);
        ...
        oPB.setProgress("Status x", 85);
        oPB.deactivate();
        // Erste Maske. Nach der Maske wird diese geschlossen
        // und die nachfolgende Methode aufgerufen (generalOptionsDone())
        oGO = new GeneralOptions(this);
    }

    public void generalOptionsDone() {
        // Ab hier bleibt die ProgressBar grau. Auch ein Thread.sleep() nachdem die Maske geschlossen 
        // wurde und bevor die ProgressBar startet, hilft nicht.
        oPB.setProgress("Stadus x", 50);
        oPB.activate();
        ...
        oPB.deactivate();
        // Zweite Maske. Hiernach wird setExtendedOptions() aufgerufen.
        oEO = new ExtendedOptions(this);
    }

    public void setExtendedOptions() {
        oPB.setProgress("Status x", 25);
        oPB.activate();
        ...
        oPB.setProgress("Status x", 33);
        ...
    }
...
}

ProgressBar:

public class ProgressBar extends JFrame {

    public ProgressBar() {
        super("Bar");
        this.setResizable(false);
        this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        this.setUndecorated(true);
        this.setCursor(new Cursor(Cursor.WAIT_CURSOR));
        this.setSize(iWidth, iHeight);
        dim = Toolkit.getDefaultToolkit().getScreenSize();
        init();
        this.setIconImage(imgFrameIcon.getImage());
        JFrameLaF.centerJFrame(this);
    }

    private void init() {
        cldr = Thread.currentThread().getContextClassLoader();
        imgURLIcon = cldr.getResource("images/icon_ams.png");
        imgFrameIcon = new ImageIcon(imgURLIcon);
        JFrameLaF.setLookAndFeelSystem(this);
        this.setContentPane(createContent());
    }

    private JPanel createContent() {
        jPnlContent = new JPanel(new GridBagLayout());
        jPnlContent.setBorder(BorderFactory.createEtchedBorder());
        GridBagConstraints c = new GridBagConstraints();

        // The text
        c.gridx = 0;
        c.gridy = 0;
        c.insets = new Insets(-5, 0, 20, 0);
        c.fill = GridBagConstraints.HORIZONTAL;
        c.anchor = GridBagConstraints.CENTER;
        jLblProgress = new JLabel();
        jLblProgress.setHorizontalAlignment(JLabel.CENTER);
        jPnlContent.add(jLblProgress, c);

        // The bar
        c.gridx = 0;
        c.gridy = 1;
        c.ipadx = 270;
        c.insets = new Insets(0, 0, 0, 0);
        jPrbProgress = new JProgressBar();
        jPrbProgress.setMinimum(0);
        jPrbProgress.setMaximum(100);
        //jPrbProgress.setSize(20, 250);
        jPrbProgress.setValue(0);
        jPrbProgress.setStringPainted(true);
        jPnlContent.add(jPrbProgress, c);

        return jPnlContent;
    }

    public void activate() {
        this.setVisible(true);
        this.repaint();
    }

    public void deactivate() {
        this.setVisible(false);
    }

    public void refresh() {
        this.repaint();
		//super.repaint();
    }

    public void setProgress(final String sPROGRESS, final int iPROGRESS) {
        jLblProgress.setText(sPROGRESS);
        jPrbProgress.setValue(iPROGRESS);
        this.repaint();
        // Problems with immediate repaint
        //jPnlContent.paintImmediately(0, 0, dim.width, dim.height);
    }

    public void close() {
        this.setVisible(false);
        this.dispose();
    }
}

Ich weiß, das sieht nicht gerade elegant aus...

 

[Michael...]

Das aktualisieren des Status der "ProgressBar" muss in einem separaten Thread passieren und nicht im EDT.

 

[Sleepwalker]

Danke für den Hinweis. Was genau meinst du mit "aktualisieren"? Die Methode refresh()? Die benutze ich derzeit gar nicht, weil sie nicht so funktioniert, wie ich es mir erhofft habe.
Mit Threads hab' ich leider nicht so die Erfahrung. Kannst du mir einen Ansatz geben?

PS: Mir ist gerade noch aufgefallen, dass ich nicht einmal die Hinterrundfarbe der ProgressBar ändern kann. Nach einem Bruchteil einer Sekunde ist der Hintergrund wieder im Standardgrau.

 

[Michael...]

Mit aktualisieren meinte ich das Setzen der Werte. Was eigentlich falsch ist, da das Setzen der Werte im EDT erfolgen sollte, während die Aktionen die rundrum in einen separaten Thread ablaufen sollten.

Anweisungen innerhalb eines Threads werden immer komplett abgearbeitet. Wenn Du in einer Methode innerhalb des EDT mehrfach hintereinander auf einer Komponente setValue/setText o.ä. machst, siehst Du am Ende nur die zuletzt vorgenommene Änderung. Werden in der Methode sogar längerwierige Aktivitäten durchgeführt, kommt es dazu das Fenster grau werden, da durch das Blockieren des EDT das Fenster nicht neu gezeichnet werden kann. (ausführlicher: Threads und nebenläufige Programmierung)

Hier mal ein Bsp. mit einer JProgressBar:

import java.awt.BorderLayout;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JProgressBar;

public class ProgressBarDemo extends JPanel {
	private JProgressBar progressBar;
	private JLabel label;
	
	public ProgressBarDemo() {
		this.setLayout(new BorderLayout());
		progressBar = new JProgressBar();
		progressBar.setStringPainted(true);
		label = new JLabel("0%", JLabel.CENTER);
		this.add(label, BorderLayout.CENTER);
		this.add(progressBar, BorderLayout.SOUTH);
		new Thread(new MyWorkerThread()).start();
	}
	
	public static void main(String[] args) {
		JFrame frame = new JFrame();
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setBounds(0, 0, 500, 300);
		frame.setLocationRelativeTo(null);
		frame.getContentPane().add(new ProgressBarDemo(), BorderLayout.CENTER);
		frame.setVisible(true);
	}
	
	class MyWorkerThread implements Runnable {
		public void run() {
			for (int i=0; i<=100; i++) {
				try {
					Thread.sleep(100);  //nur zur Demo - Ersatz für zeitaufwändige Aktionen
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
				label.setText(i + "%");
				progressBar.setValue(i);
			}
		}
	}
}

 

[Sleepwalker]

Ich weiß, was du meinst, dass das eigentlich falsch herum ist. Mir würde es in diesem Fall aber auch "falsch" ausreichen, weil sich der Aufwand des Umschreibens für das bestehende Projekt nicht lohnt. Für Spätere werde ich das dann von Anfang an "richtig" machen.

Das Problem ist ja, dass ich die Werte aus der Controller-Klasse setze, wenn gewisse Ereignisse eingetroffen sind. Wenn ich jetzt die ProgressBar in einem Thread starte, kann ich ja kein setProgress() mehr aufrufen.

 

[Michael...]

Das Problem ist ja, dass ich die Werte aus der Controller-Klasse setze, wenn gewisse Ereignisse eingetroffen sind.

Die den Ereignissen vorrausgehenden Aktivitäten scheinen ja etwas zeitaufwändiger zu sein, diese müssen im Thread abgearbeitet werden.

weil sich der Aufwand des Umschreibens für das bestehende Projekt nicht lohnt

Da wirst Du wohl nich drum rum kommen.

 

[Sleepwalker]

Verdammt.
Während dieser aufwändigen Aktivitäten arbeite ich jeweils immer mit ein und demselben Objekt.
Dann müsste ja der Thread dieses Objekt erstellen und sich an gewissen Punkten selbst unterbrechen. Und ich müsste in meiner Controller-Klasse genau wissen, was im Thread passiert ist. Dann aktualisiere ich die ProgressBar und starte den Thread an der angehaltenen Stelle wieder?
Oder wie sieht dann das Vorgehen aus? Ich brech' mir da gerade total einen bei ab, mir das im Kopf zurecht zu basteln.
Wie kommuniziere ich denn mit dem Thread und er mit mir?

 

[Michael...]

Du musst ja nicht mit dem Thread kommunizieren. Es reicht vermutlich aus, wenn der Thread die ProgressBar kennt und eine Referenz auf die folgende Maske besitzt.
Eingabemaske1: Anwender klickt auf OK --> "Ladebalken" wird sichtbar, neuer Thread startet, der die notwendigen Verarbeitungen vornimmt und an den entsprechenden Stellen den "Ladebalken" aktualisisert.
Der Thread ist fertig --> nächst Maske wird angezeigt und wartet auf Benutzereingaben.
Eingabemaske2: Anwender klickt auf OK --> usw.

Mit CardLayout bzw. nur einem JFrame ginge das sicherlicher viel einfacher.

 

[Sleepwalker]

Das nächste Mal nehme ich auch gleich ein CardLayout Aber hier variieren die Fenstergrößen leider zu sehr.

Ich habe nun die ProgressBar als Thread erstellt und diesem die Controller-Klasse als Referenz übergeben (der Einfachheit halber, weil der Weg "anders herum" zu aufwändig ist).
In der Controller-Klasse ändere ich jetzt Attribute, die die ProgressBar jede halbe Sekunde abfragt.
Ansich funktioniert das auch, aber: Die ProgressBar bleibt nach dem ersten Eingabefenster immer noch grau...bevor die erste Maske erscheint geht sie nach wie vor einwandfrei.

Controller-Codeschnipsel

bWaitState = true;
tPB = new Thread(new ProgressBar(this));
tPB.start();
setWaitStateText("Status x");
setWaitStatePercent(0);

Die run-Methode der ProgressBar sieht nun so aus:

public void run() {
    while(true) {
        try {
            Thread.sleep(500);
            if (controller.getWaitState() == true) {
                if (!bIsVisible) {
                    activate();
                }
                this.setProgress(controller.getWaitStateText(), controller.getWaitStatePercent());
                this.repaint();
            } else {
                deactivate();
            }
        } catch (InterruptedException ex) {
            Logger.getLogger(ProgressBar.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

Ist da jetzt wieder ein Denkfehler drin, dass die ProgressBar grau bleibt? Meine Tischkante hat schon bissspuren.

 

[Michael...]

Die den Ereignissen vorrausgehenden Aktivitäten scheinen ja etwas zeitaufwändiger zu sein, diese müssen im Thread abgearbeitet werden.

Die ProgressBar im/als Thread nützt nichts, der Bearbeitungsprozess muss aus dem EDT raus in einen eigenen Thread.

 

[Sleepwalker]

Argh, das ist ja zum Mäuse melken. Ich dachte, die Bar als Thread würde ggf. schon helfen, damit die "für sich" aktualisiert werden kann.
Ich mag Threads nicht.

Dann versuche mal ich bei Gelegenheit den Controller umzuschrieben.
Werde mich dann wieder hier melden.
Vielen Dank schon einmal, Michael...

PS: Ist es ok, wenn man im Controller ein paar Loops hat, die drauf warten, dass der Thread Attribute ändert? Ich meine, gehen würde es (mein Code nur anders herum), aber kann man das auch als "akzeptablen" Code ansehen?

 

[Michael...]

PS: Ist es ok, wenn man im Controller ein paar Loops hat, die drauf warten, dass der Thread Attribute ändert?

Warten - im Sinne von pausieren/aktiv warten - innerhalb des EDT ist grundsätzlich schlecht. Wenn Du aber Warten im Sinne von Überwachen (Listener bzw. Observer-Observable-Konzept) denkst, ist das i.O. Vermute aber mal Du sprichst von ersterem.

Grundsätzlich gilt: Alles was im EDT läuft sollte möglichst wenig Zeit benötigen.

 

[Sleepwalker]

Ich würde einfach mit Thread.sleep(1000) warten wollen. Der Controller wartet in dem Fall ja ohnehin nur darauf, dass der Thread fertig wird (und zeigt die ProgressBar an).
Das Observer-Pattern ist für mich genauso ein hakeliges Thema wie Threads. Theoretisch ok, praktisch ist's "uah"...

 

[Michael...]

Ich würde einfach mit Thread.sleep(1000) warten wollen.

Wenn das aber im EDT aufgerufen wird, wird auch während dieser Zeit das Neuzeichnen blockiert und wenn der Anwender in der Zeit etwas an der GUI macht --> grau

 

[Sleepwalker]

Moin,

also, ich habe jetzt ein kleines Beispiel mit Thread & Observer am Laufen. Das sieht alles halb so wild aus, wie gedacht. So kann ich mit nur einem einzigen Thread meine Aufgabe erledigen.

Frage: Ich kann ja nun dem Controller (Observer, der im EDT läuft) nicht gerade viele Daten beim notifyObservers() mitgeben. Wenn ich aber jetzt mit dem Controller Daten austauschen will (String und Integer), ist es sinnvoll, das über set-Methoden im Controller zu machen, die ich vor dem notifyObservers() aufrufe? Oder gibt es da elegantere Möglichkeiten? Oder ist das vielleicht dann wieder "hinderlich"?

PS: Oder auch get-Methoden im Observable?

PPS: Was bin ich blind. Ich kann ja auch einfach ein neues Objekt mit den Werten übergeben. Hat sich glaub' ich erledigt Es sei denn meine Theorie liegt irgendwo daneben.

Vielen Dank.

Gruß,

Tobias

 

[Sleepwalker]

Morgen,

ich hab' jetzt immer einen aktuellen Fortschrittsbalken Danke, Michael...

Also...
- Mein Controller steuert jetzt den Ladebalken (ist ja nicht so aufwendig)
- Die aufwendigen arbeiten sind in einem extra Thread, der den Controller (Observer) immer benachrichtigt, wenn sich der Ladebalken / Infotext ändern soll.
- Die Eingabemasken werden derzeit immer noch im o.g. Thread erzeugt. Der Thread wartet in einer sleep-Schleife darauf, dass der Benutzer fertig ist.

Frage: Kann man den letzten Punkt ohne sleep() lösen? Das stört zwar jetzt nicht mehr, weils nicht im EDT ist, aber vllt. gehts ja etwas effizienter? Die Masken lasse ich einfach mal im Thread, weil sie da meines Erachtens nach am besten aufgehoben sind. Oder?!
Danke.

Gruß,

Tobias