# Splash Screen / "Loading" Anzeige im Programm



## Sparkle (3. Mrz 2009)

Hi all,

Habe hier ein Problem, bei dem ich gar nicht weiterkomme. Sitze schon den ganzen Abend dran und habe alles mögliche ausprobiert, aber jetzt bin ich mit meinem Latein am Ende.

Es geht darum, dass ich innerhalb des laufenden Programms einen "Splash-Screen" anzeigen will (mit einem Bild), der so lange sichtbar sein soll, wie das Laden der Daten dauert. Genauer gesagt befindet sich am Anfang des Programms ein Dialog, der nach einem Login fragt, da soll der User was eingeben und nach Bestätigung der Eingabe werden dann verschiedene Daten geladen, was teilweise einige Sekunden braucht. Während dieser Sekunden soll ein solcher Ladebildschirm angezeigt werden. Nachdem alles geladen ist, soll er dann wieder verschwinden.

Nur leider funzt es nicht. Ich habe JDialog, JWindow, JFrame und JweißderGeierwasnochalles ausprobiert -> nichts. Wenn ich setVisible auf true setze, bevor dieser Start-Login-Dialog kommt, dann zeigt er den Ladebildschirm ganz normal an, samt Bild (ist halt der falsche Zeitpunkt). Wenn ich setVisible erst nach dem Login-Dialog auf true setze, dann erscheint bestenfalls ein durchsichtiges Fenster ohne das Bild. Ich verstehe einfach nicht, warum er das nicht anzeigen will. Ich hatte auch die Vermutung, dass er vielleicht das Bild noch nicht geladen hat und sich dann nicht mehr damit beschäftigen will beim Daten-Laden, aber auch da kein Erfolg: Ich habe ImageIO, Toolkit, Label-ImageIcon, MediaTracker, BufferedImage usw. probiert, aber daran liegt es wohl nicht, denn davon hat nichts geholfen. Auch wenn ich nur ein Label mit einem Text hinzufüge, wird der Ladebirdschirm nicht angezeigt. Das einzige, was man sieht (vorausgesetzt Decorations sind an), ist die Titelleiste - und eben das durchsichtige ContentPane.

Weiß jemand, an was das liegt?

Ich habe mir auch überlegt, ob es vielleicht schlau wäre, das mit Threads hinzubiegen, aber da hab ich keine Ahnung, wie ich das bewerkstelligen soll. Bei Google finden sich manche Hinweise auf SwingWorker, aber ich blicke da nicht wirklich durch. Auch eine Suche hier hat mich dahingehend nicht weitergebracht. Vielleicht ist es auch ganz der falsche Pfad.

Ich wär echt glücklich, wenn mir jemand meinen Denkfehler aufzeigt. Irgendwie kommt es mir so vor, als würde ich was übersehen. Es macht mich auf jeden Fall wahnsinnig 

Danke schon mal für die Antworten.


----------



## Ebenius (3. Mrz 2009)

Es liegt ziemlich sicher daran, dass Du etwas bezüglich Threads im Swing falsch verstanden hast. Am besten Du liest oder überfliegst mal Sun Java Tutorial » Lesson: Concurrency in Swing. Lohnt sich!

Ebenius


----------



## Sparkle (3. Mrz 2009)

Schon geschehen. Wie gesagt, mir leuchtet nicht ein, wie ich SwingWorker einsetzen sollte. Ich schreibe bei doInBackground() meinen zeitintensiven Task rein, bei done() verarbeite ich ihn mit get() weiter und setze splashScreen.setVisible(false). Danach schreibe ich worker.execute(), damit auch passiert, was drinsteht. Und dann noch ein while (!worker.isDone()) {}; , damit der EDT wartet, bis die Berechnung passiert ist. Der Witz ist, dass der Ladebildschirm trotzdem nicht angezeigt wird, obwohl er vor dem SwingWorker-Abschnitt im Code steht und doch eigentlich parallel im EDT laufen sollte. Spätestens da, wo der EDT dann untätig durch die leere Schleife saust, müsste doch genügend Zeit da sein, das Lade-Bild zu laden und den Ladebildschirm anzuzeigen, oder nicht?


Zum Überblick hier mal der Codeausschnitt:
[HIGHLIGHT="Java"]        JDialog splashScreen = new JDialog();
        Image img = Toolkit.getDefaultToolkit().createImage("images/splash.jpg");  
        JLabel splashImage = new JLabel(new ImageIcon(img));
        splashScreen.getContentPane().add(splashImage);
        //splashScreen.setUndecorated(true);
        //splashScreen.setSize(300, 300);
        splashScreen.pack();
        splashScreen.setLocationRelativeTo(this);
        splashScreen.setVisible(true);

        final JDialog splashS = splashScreen;

        SwingWorker worker = new SwingWorker<Ergebnis, Void>() {
            @Override
            public Ergebnis doInBackground() {
            	// zeitintensiver Task *ratter ratter*
            	return ergebnisVomTask;
            }

            @Override
            public void done() {
            	splashS.setVisible(false);
                try {
                	aPanel.add(get());
                	System.out.println("Geschafft.");
                } catch (InterruptedException ignore) {}
                catch (java.util.concurrent.ExecutionException e) {
                    String why = null;
                    Throwable cause = e.getCause();
                    if (cause != null) {
                        why = cause.getMessage();
                    } else {
                        why = e.getMessage();
                    }
                    System.err.println("Error: " + why);
                }
            }
        };
        worker.execute();

        while (!worker.isDone()) {};  [/HIGHLIGHT]


----------



## Ebenius (3. Mrz 2009)

Sparkle hat gesagt.:


> Spätestens da, wo der EDT dann untätig durch die leere Schleife saust, müsste doch genügend Zeit da sein, das Lade-Bild zu laden und den Ladebildschirm anzuzeigen, oder nicht?


Was?

Nimm die Schleife weg und lass die Methode zurückkehren! Der Thread muss doch weiter arbeiten können, sonst ergibt alles keinen Sinn!

Ebenius


----------



## 0001001 (3. Mrz 2009)

Ohne deinen Code jetzt angeschaut zu haben, hier ein Beispiel das ich öfters verwende:
[HIGHLIGHT="Java"]public class StartupWorker extends SwingWorker<String,Void>{
       @Override
	/**
	 * all methods called in this function
	 * are done in the background and will not
	 * block the GUI
	 */
	protected String doInBackground(){

		// put your time consuming tasks here
		return ""; 
	}


	protected void done(){		
		// close splash screen
		SwingUtilities.invokeLater(new Runnable(){
			public void run(){
				SplashWindow.disposeSplash();	
			}
		});


		// show main window
		SwingUtilities.invokeLater(new Runnable(){
			public void run(){
				new MainWindow(); // start main gui	
			}
		});			
	}	
}[/HIGHLIGHT]


[HIGHLIGHT="Java"]import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Font;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JWindow;
import javax.swing.SwingUtilities;

import org.mn.util.GUIUtil;




public class SplashWindow extends JWindow{

    /**
     * The current instance of the splash window.
     * (Singleton design pattern).
     */
    private static SplashWindow instance;
    private JLabel txt;

    private SplashWindow(JFrame parent){
    	super(parent);
    	super.setLayout(new BorderLayout());
    	txt = new JLabel(""); //$NON-NLS-1$
    	txt.setFont(new Font("Arial", Font.PLAIN, 10)); //$NON-NLS-1$
    	txt.setForeground(Color.WHITE);
    	super.getContentPane().setBackground(Color.BLACK);
    	JLabel icon = new JLabel(GUIUtil.getImageIcon(this,"/images/splashscreen.png")); //$NON-NLS-1$
    	super.add(txt,BorderLayout.SOUTH);
    	super.add(icon,BorderLayout.CENTER);
        // Center the window on the screen
        int imgWidth = icon.getSize().width;
        int imgHeight = icon.getSize().height;
        super.setSize(imgWidth, imgHeight);    	
    }



	public static void splash(){
		if(instance == null){
			JFrame f = new JFrame();
			instance = new SplashWindow(f);
			instance.pack();
			instance.setVisible(true);
			instance.setLocationRelativeTo(null);
		}
	}

    public static void disposeSplash() {
        if (instance != null) {
            instance.getOwner().dispose();
            instance = null;
        }
    }

    /**
     * Invokes the main method of the provided class name.
     * @param args the command line arguments
     */
    public static void invokeMain(String className, String[] args) {
        try {
            Class.forName(className)
            .getMethod("main", new Class[] {String[].class}) //$NON-NLS-1$
            .invoke(null, new Object[] {args});
        } catch (Exception e) {
            InternalError error = new InternalError("Failed to invoke main method"); //$NON-NLS-1$
            error.initCause(e);
            throw error;
        }
    }



	public static SplashWindow getInstance() {
		return instance;
	}


	public static void setInstance(SplashWindow instance) {
		SplashWindow.instance = instance;
	}


	/**
	 * Updates the text on the loading screen
	 * @param aText
	 */
	public void setTxt(String aText) {
		final String a = aText;
		SwingUtilities.invokeLater(new Runnable(){
			public void run(){
				txt.setText(a);
			}
		});		
	}    
}[/HIGHLIGHT]


----------



## DarkLoG (3. Mrz 2009)

worker.execute();

while (!worker.isDone()) {};


Mit der Schleife hälst du ja den EDT an, dann kannst du dir den Swingworker sparen, nee nee so wird das nix, am besten wirklich nochmal den Artikel über Threads lesen... wie von Ebenius schon geschrieben, die Schleife muss weg!

Gruß

DarkLoG


----------



## Illuvatar (3. Mrz 2009)

Falls du Java 6 verwendest, kannst du dir auch mal das hier anschauen:
New Splash-Screen Functionality in Java SE 6


----------



## thE_29 (3. Mrz 2009)

Ansonsten guck mal in die FAQ


----------



## Ebenius (3. Mrz 2009)

Illuvatar hat gesagt.:


> Falls du Java 6 verwendest, kannst du dir auch mal das hier anschauen:
> New Splash-Screen Functionality in Java SE 6


Eigentlich handelt es sich hier nicht um einen Splash Screen, sondern viel mehr um einen Progress Dialog (oder so ähnlich).

Hilft vielleicht der ProgressMonitor dafür? Siehe: Sun Java Tutorial » How to Use Progress Bars (ab der Mitte der Seite).

Ebenius


----------



## thE_29 (3. Mrz 2009)

Naja, sicher ist das ein SplashScreen!
Die Frage ist halt was der Unterschied ist zwischen einem Progressbar/monitor und SplashScreen


----------



## Ebenius (3. Mrz 2009)

thE_29 hat gesagt.:


> Naja, sicher ist das ein SplashScreen!


Zumindest die deutsche Wikipedia widerspricht Dir.

Ebenius


----------



## DarkLoG (3. Mrz 2009)

thE_29 hat gesagt.:


> Naja, sicher ist das ein SplashScreen!
> Die Frage ist halt was der Unterschied ist zwischen einem Progressbar/monitor und SplashScreen



Der Unterschied ist dass man bei ner Progressbar kaum auf die Java 6 Funktionalität - SplashScreen zurückgreifen kann oder?

Gruß

DarkLoG


----------



## Ebenius (3. Mrz 2009)

Das wird ja immer verwirrender. Nochmal zum Mitmeißeln: Der Themeneröffner möchte keinen Splashscreen haben. Ein SplashScreen ist ein Startbild. Dafür und für nichts anderes ist die SplashScreen-Klasse gedacht. Das sagt doch die API-Doc ganz deutlich.

Ebenius


----------



## Illuvatar (3. Mrz 2009)

Kann man schon (siehe Beispielcode in dem oben verlinkten Artikel)

Die Frage ist allerdings immer, ob es in dem entsprechenden Kontext Sinn macht. Da muss man möglicherweise einiges an Code neu schreiben, der in ProgressMonitor oder so schon enthalten ist.

Edit: Bezog sich auf DarkLoG


----------



## DarkLoG (3. Mrz 2009)

Illuvatar hat gesagt.:


> Kann man schon (siehe Beispielcode in dem oben verlinkten Artikel)
> 
> Die Frage ist allerdings immer, ob es in dem entsprechenden Kontext Sinn macht. Da muss man möglicherweise einiges an Code neu schreiben, der in ProgressMonitor oder so schon enthalten ist.
> 
> Edit: Bezog sich auf DarkLoG



Ja hmm klar ich sag mal so machen kann man immer alles, aber das schöne an der Splashscreen-Funktion ist doch gerade dass ich mit "java -splash:filename.gif SplashTest" genau das bekomme, was ich mir unter einem Splashscreen vorstelle.

Gruß

DarkLoG

PS: @Ebenius - ist klar, er will nen Progress-Screen...


----------



## thE_29 (3. Mrz 2009)

@Ebenius: Achso, der TE will keinen Splashscreen 
Ich habe aber auch bei meinen SplashScreens eine Ladeanzeige! Sodaß man noch mehr Aktionen sieht..

Aber wenn er nen ProgressScreen will, habe ich den falsch verstanden


----------



## Ebenius (3. Mrz 2009)

thE_29 hat gesagt.:


> @Ebenius: Achso, der TE will keinen Splashscreen
> Ich habe aber auch bei meinen SplashScreens eine Ladeanzeige! Sodaß man noch mehr Aktionen sieht..
> 
> Aber wenn er nen ProgressScreen will, habe ich den falsch verstanden


Ich hab sowas auch. Aber der Themeneröffner möchte wohl einen Ladebalken in einem Dialog oder Popup, während das Programm bereits mit Fenster etc. läuft.

Was so ein falsches Wort alles ausmachen kann... 

Ebenius


----------



## Sparkle (3. Mrz 2009)

Jo, die Überschrift ist da wahrscheinlich missverständlich, ich wusste nur nicht, wie man das Ding nennt.

@DarkLog und Ebenius: Wenn ich die Schleife weglasse, dann ladet er natürlich die GUI weiter. Aber das ist ja grade nicht gewollt, denn das Ergebnis aus dem Worker-Thread ist ja wichtig für das, was die GUI nachher anzeigen soll. Es soll schlicht und einfach ein Bild angezeigt werden in einem eigenen Dialog/Window/Frame/etc, während der Worker-Thread arbeitet. Wenn der Worker-Thread dann fertig ist, soll das Bild verschwinden und die GUI bzw. der EDT soll weitermachen.

Hier mal ein Bild zur Verdeutlichung, was ich meine:







@0001001: Danke, das werd ich mal ausprobieren.

@Illuvatar: Die SplashScreen-Funktion ist leider nicht das, was ich suche. Es soll ja mehr oder weniger mitten im Programm passieren, nicht anfangs.

Die meisten Beispiele zu SwingWorker und Konsorten beziehen sich (verständlicherweise) darauf, die GUI durch Auslagern in einen Thread bedienbar zu halten. Darum geht es mir aber gar nicht. Wenn das Ladebild angezeigt wird, kann das Programm währenddessen ruhig "gefreezt" wirken (wäre zumindest ein Anfang, mit dem man kurz leben könnte). Mein Wunsch wäre ein while(isWorking) showLadeBildschirm()  Habe mir grade mal ProgressMonitor angeschaut. Das kommt dem recht nahe, was ich will. Mein Problem damit ist, dass ich dann den kompletten Code, der im Weiteren die GUI mit den berechneten Daten ladet, in propertyChange() reinschreiben müsste. Ist das der Sinn der Sache?

Irgendwie steige ich immer noch nicht so ganz durch. Werde mich mal weiter durchwühlen... für Tipps und Schubser in die richtige Richtung bin ich sehr dankbar =) Thx schonmal für eure Hilfe.

Grüße,
Sparkle


----------



## Ebenius (3. Mrz 2009)

Ein möglicher Schubser wäre "Modaler Dialog" 

Ebenius


----------



## DarkLoG (3. Mrz 2009)

Naja wenn die GUI quasi stehen soll wozu dann der SwingWorker? Dann zeig doch einfach das Bild an, und starte anschließend deinen "Ratter,Ratter"-Teil und sobald der Teil fertig ist, kannst du das Fenster,Bild,Dialog was auch immer schließen und ganz normal weiter machen, ich sehe jetzt irgendwie das Problem nicht mehr ??

Gruß

DarkLoG

Ps: Ich hab meinem aktuellen Projekt einen modalen Dialog der autom. erscheint sobald die Verbindung zum Server 
abgebrochen ist und verschwindet dann wieder wenn die Verbindung wieder da ist, die Verbindungs-Überwachung ist natürlich ein eigener Thread der dann über mein Messaging-System ne Nachricht an den Controller des Dialogs schickt, aber ich denke so aufwendig musst du es nicht machen, wenn die GUI wirklich hängen darf. Bei mir darf sie nicht hängen weil der User die Möglichkeit hätte in dem Dialog das ganze Programm zu schließen, außerdem finde ich sind "hängende" GUIs ein absolutes NoGo... aber in deinem Fall fällts vielleicht gar nicht so auf.


----------



## Ebenius (3. Mrz 2009)

DarkLoG hat gesagt.:


> Naja wenn die GUI quasi stehen soll wozu dann der SwingWorker? Dann zeig doch einfach das Bild an, und starte anschließend deinen "Ratter,Ratter"-Teil und sobald der Teil fertig ist, kannst du das Fenster,Bild,Dialog was auch immer schließen und ganz normal weiter machen, ich sehe jetzt irgendwie das Problem nicht mehr ??


Das war jetzt mal nix. Wenn er die Aktion im EDT ausführt, dann kann der nicht mehr zeichnen. Wie soll dann der Progress aktualisiert werden? Und wie soll neu gezeichnet werden, wenn man ein Fenster drüber legt und wieder weg nimmt. Und, und, und...

Ebenius


----------



## Sparkle (3. Mrz 2009)

@DarkLog: Ja, genau das war mein Gedanke  Aber wie ich leider sehen muss, funktioniert es nicht, eben weil der EDT nicht mehr zeichnet (warum auch immer). Finde ich tröstlich, dass dich das auch etwas verwirrt. Du hast auch recht, dass hängende GUIs - zumal ohne Einwirkungsmöglichkeit - ein No-Go sind... in meinem Fall allerdings schwer zu umgehen. Eine Progressbar wäre natürlich durchaus möglich, ich wollte so einen ProgressScreen aber natürlich erstmal auf einfachstem Weg einbauen, bevor ich ihn ausschmücke - ja, und da bin ich schon gescheitert 

@Ebenius: Modaler Dialog ist kein schlechtes Stichwort. So wie ich das verstanden habe, muss ich da nur mit setModal() rumspielen, oder? Falls ja, habe ich das schon probiert, brachte allerdings nicht das erhoffte Ergebnis, eben weil der EDT dann bisher am zeitintensiven Teil gerechnet hat, anstatt mal einfach den Dialog anzuzeigen.

Das mit dem ProgressMonitor und propertyChange() könnte tatsächlich hinhauen. Ich müsste dazu zwar den Code ziemlich umarbeiten, aber einen Versuch wär es wert. Muss mich allerdings jetzt erstmal anderem zuwenden; ich bastle später weiter und melde mich dann nochmal.

Grüße,
Sparkle


----------



## Ebenius (3. Mrz 2009)

Vielleicht hilft ja dieses Beispiel weiter: [HIGHLIGHT="Java"]public class ProgressDialogTest {

  static class MyTask extends SwingWorker<String, Integer> {

    int value;
    private final JProgressBar progressBar;
    private final JDialog dialog;

    MyTask(JDialog dialog, JProgressBar progressBar) {
      this.dialog = dialog;
      this.progressBar = progressBar;
    }

    @SuppressWarnings("boxing")
    @Override
    public String doInBackground() {
      while (!isDone() && !isCancelled()) {
        try {
          Thread.sleep(50);
        } catch (InterruptedException ex) {
          ex.printStackTrace();
          // Ignore me 
        }
        publish(value);
        setProgress(++value);
      }
      return "Done";
    }

    @Override
    protected void process(List<Integer> chunks) {
      for (int progress : chunks) {
        progressBar.setValue(progress);
      }
    }

    @Override
    protected void done() {
      dialog.setVisible(false);
    }
  }

  /**
   * Test main method.
   * 
   * @param args ignored
   */
  public static void main(String[] args) {
    SwingUtilities.invokeLater(new Runnable() {

      @Override
      public void run() {
        createAndShowGUI();
      }
    });
  }

  private static void createAndShowGUI() {
    final JPanel panel = new JPanel(new BorderLayout(6, 6));
    panel.add(new JLabel("Useless Filler"));
    panel.add(new JButton(new AbstractAction("Start the progress") {

      @Override
      public void actionPerformed(ActionEvent e) {
        final Component src = (Component) e.getSource();
        final Frame frame = (Frame) SwingUtilities.getWindowAncestor(src);
        final JDialog dialog = new JDialog(frame);
        final JProgressBar progressBar = new JProgressBar(0, 100);
        dialog.add(new JLabel("Doing Something ... Hold the Line ..."),
              BorderLayout.CENTER);
        dialog.add(progressBar, BorderLayout.SOUTH);
        dialog.pack();
        dialog.setLocationRelativeTo(frame);
        dialog.setModal(true);
        dialog.setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE);

        new MyTask(dialog, progressBar).execute();
        dialog.setVisible(true);
      }
    }), BorderLayout.SOUTH);

    final JFrame f = new JFrame("Swing Worker");
    f.setContentPane(panel);
    f.pack();
    f.setLocationRelativeTo(null);
    f.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
    f.setVisible(true);
  }
}[/HIGHLIGHT]

Ebenius


----------



## DarkLoG (3. Mrz 2009)

Ebenius hat gesagt.:


> Das war jetzt mal nix. Wenn er die Aktion im EDT ausführt, dann kann der nicht mehr zeichnen. Wie soll dann der Progress aktualisiert werden? Und wie soll neu gezeichnet werden, wenn man ein Fenster drüber legt und wieder weg nimmt. Und, und, und...
> 
> Ebenius



Nee das war schon was , von Progress aktualisieren hab ich nix gelesen bis jetzt und Fenster drüber legen?? ist nich wenn die GUI hängt z.b. bei nem MDI oder so,  außer du redest jetzt von Fenstern von anderen Applikationen? Das ist was anderes bis jetzt bin ich aber nur davon ausgegangen dass einfach wie du selbst geschrieben hast ein modaler Dialog dargestellt (mit statischem Inhalt natürlich) wird -> EDT rattert weiter -> User kann weder Eingaben noch sonst was machen-> Ratter fertig -> Dialog setVisible(false), sehe da keinen Fehler, aber ich lass mich gerne aufklären?? Davon mal abgesehen hab ich ja geschrieben dass ich GUIs die hängen niemals akzeptieren würde, und sowas persönlich immer in nem Thread oder Swingworker etc. abhandeln würde.

Gruß

DarkLoG


----------



## Ebenius (4. Mrz 2009)

DarkLoG, entweder ich verstehe Dich falsch, oder es funktioniert so einfach nicht. Kannst Du mal kurz nen ActionListener basteln, der das macht was Du willst? Nur zum durchlesen, muss nicht ausführbar sein. Vielleicht verstehe ich's ja dann besser.

Ebenius


----------



## Sparkle (4. Mrz 2009)

Geschafft!!

Vielen, vielen Dank für eure Hilfe 

Neben einigen Denkfehlern, die ich durch eure Hinweise irgendwann überwunden hatte, war das Hauptproblem, dass ich den SwingWorker-Thread aus dem Hauptframe aufrief, direkt nachdem der Anfangsdialog fertig war, und nicht aus dem Anfangsdialog selbst.

Thx & Grüße,
Sparkle


----------



## DarkLoG (5. Mrz 2009)

Ebenius hat gesagt.:


> DarkLoG, entweder ich verstehe Dich falsch, oder es funktioniert so einfach nicht. Kannst Du mal kurz nen ActionListener basteln, der das macht was Du willst? Nur zum durchlesen, muss nicht ausführbar sein. Vielleicht verstehe ich's ja dann besser.
> 
> Ebenius



Hmm es scheint als hättest du Recht ich habs mal schnell in ein Testprogramm von mir eingebaut. (Wie kann ich hier vernünftig Code posten, sorry bin noch neu, werd gleich mal sehen ob es irgendwo in den FAQs steht) Wenn der Dialog modal ist passiert natürlich gar nichts mehr, da hatte ich nen Denkfehler das stimmt, aber wenn er nicht modal ist, läuft der Ratter-Teil nach Dialog.setVisible(true) schon weiter allerdings wird der Dialog nur halb gezeichnet. Kannst du mir erklären wieso das so ist, ich meine zumindest einmal hätte der EDT doch den Dialog ganz zeichnen müssen bevor er weiter macht?? Wenn man den Dialog dann verschiebt passiert natürlich Müll weil der EDT nicht aktualisieren kann das ist klar und von daher sollte man es sowieso gleich von anfang an vernünftig lösen.

Gruß

DarkLoG

Edit: Zeigt man den ProgressDialog an und startet den Ratter-Teil über einen Listener (Button etc.) aus dem Dialog dann ist es das was ich ursprünglich im Kopf hatte, der Dialog bleibt sauber zu sehen (kann auch verschoben werden) und der EDT rattert vor sich hin. Natürlich kann der Dialog dann nicht geschlossen werden und auch sonst reagiert die GUI nicht, davon mal abgesehen ist natürlich auch nicht das was der TE wollte denn die Aktion soll ja wohl kaum aus dem Dialog raus gestartet werden, aber ich hoffe es ist jetzt klarer worauf ich hinaus wollte?
So und jetzt vergessen wir alle diese Lösung wieder und bleiben bei der vernünftigen


----------



## Ebenius (5. Mrz 2009)

Bezüglich Zeichnen in AWT / Swing hab kannst Du gern hier nochmal lesen: Problem bzw. Sinn von Graphics / Graphics Context.

Code postet man in HIGHLIGHT-Tags; also so: [*HIGHLIGHT="Java"] Quelltext [*/HIGHLIGHT] <== Sterne weglassen.

Wenn Du im Kontrollzentrum bei den Einstellungen den Standard-Editor auswählste und auf einen Beitrag antwortest (also nicht das Quick-Reply, sondern über den Antworten / Zitieren / Ändern-Button), dann hast Du über dem Textfeld Buttons; einer davon für Java-Code.

Ebenius


----------

