[Java] SwingWorker , setProgress events pas na einde gezien

[Red devil]

Beste Tweakers,

Een intensieve rekenjob wil ik graag uit de UI houden middels een SwingWorker. Wel zou ik graag op de hoogte willen blijven d.m.v. een progressbar. Heb een SwingWorker gemaakt wiens doInBackground methode ik heb overrided.. Elke procent voortgang wordt middels een setProgress bijgewerkt:

De SwingWorker weet via een PropertyChangeListener dat hij daar zijn events mag plempen:

Java:

LoadStuff loadG = new LoadStuff ();

        // A property listener used to update the progress bar
        PropertyChangeListener listener =
                new PropertyChangeListener() {

                    public void propertyChange(PropertyChangeEvent event) {
                        if ("progress".equals(event.getPropertyName())) {
                            System.out.println("propertyname: "+ event.getPropertyName() + " setting progressbar with value: " + event.getNewValue());
                            progressBar.setValue((Integer) event.getNewValue());
                        }
                    }
                };
        loadG.addPropertyChangeListener(listener);
        loadG.execute();

De voortgang percentages worden via setProgress bijgewerkt, echter, pas als de SwingWorker klaar is komen ze voorbij hobbelen:

code:

propertyname: progress setting progressbar with value: 99
propertyname: progress setting progressbar with value: 1
propertyname: progress setting progressbar with value: 2
propertyname: progress setting progressbar with value: 3
propertyname: progress setting progressbar with value: 4
propertyname: progress setting progressbar with value: 5
propertyname: progress setting progressbar with value: 6
propertyname: progress setting progressbar with value: 7
propertyname: progress setting progressbar with value: 8
propertyname: progress setting progressbar with value: 9
propertyname: progress setting progressbar with value: 10
etc naar de 99

Doe ik iets niet goed?
Overigens stuur ik via een TimerAction later dezelfde ProgressBar aan wat perfect gaat, dus aan de ProgressBar zal het waarschijnlijk niet liggen.

[Gerco]

Kun je de code eens posten die de property verandert? Misschien moet je dat op de swing thread doen ofzo. Ik heb geen ervaring met SwingWorker verder, dus ik kan het natuurlijk helemaal mis hebben

[Red devil]

Gerco schreef op woensdag 16 september 2009 @ 17:10:
Kun je de code eens posten die de property verandert? Misschien moet je dat op de swing thread doen ofzo. Ik heb geen ervaring met SwingWorker verder, dus ik kan het natuurlijk helemaal mis hebben

De propertie verander je in de SwingWorker code in de doInBackGround methode o.id. en dat is alleen maar
setProgress(int progress)
Veel meer dan dat is het eigenlijk niet vrees ik ....

[Gerco]

Probeer eens om die setProgress op de Swing event thread uit te voeren? Iets als:

Java:

SwingUtilities.invokeLater(new Runnable() {
  public void run() {
    setProgress(amountOfProgress);
  }
}

[Red devil]

Gerco schreef op woensdag 16 september 2009 @ 21:05:
Probeer eens om die setProgress op de Swing event thread uit te voeren? Iets als:

Java:

SwingUtilities.invokeLater(new Runnable() {
  public void run() {
    setProgress(amountOfProgress);
  }
}

Thanks, werkt jammergenoeg niet. Snap niet hoe het zo kan... even verder nadenken :-)

[Gerco]

Dan lijkt het erop dat er toch iets de Swing thread aan het bezighouden is. Misschien niet direct je SwingWorker, maar toch iets.

Kun je bijvoorbeeld het Window resizen tijdens de operatie, werkt de redraw dan goed? Kun je op andere knoppen drukken? Als dat allemaal niet werkt, loopt je operatie (of een andere) waarschijnlijk *niet* in de achtergrond zoals je bedoeling is.

[Red devil]

Gerco schreef op donderdag 17 september 2009 @ 09:51:
Dan lijkt het erop dat er toch iets de Swing thread aan het bezighouden is. Misschien niet direct je SwingWorker, maar toch iets.

Kun je bijvoorbeeld het Window resizen tijdens de operatie, werkt de redraw dan goed? Kun je op andere knoppen drukken? Als dat allemaal niet werkt, loopt je operatie (of een andere) waarschijnlijk *niet* in de achtergrond zoals je bedoeling is.

Je hebt gelijk, zodra ik ga resizen gaat ie raar doen, na inladen ineens een redraw. Nu nog erachter komen waarom hij alsnog de Swing thread gebruikt. Zo'n SwingWorker is toch gemaakt om in een eigen thread te werken?

[Nick_S]

Als ik de uitleg en de voorbeelden in de API van SwingWorker bekijk, gebruik je hem goed.

Ik denk dat iets anders op je Swing thread zit te blocken. Roep je toevallig de get van de SwingWorker? Deze is namelijk wel blocking.

[Red devil]

Nick_S schreef op donderdag 17 september 2009 @ 10:52:
Als ik de uitleg en de voorbeelden in de API van SwingWorker bekijk, gebruik je hem goed.

Ik denk dat iets anders op je Swing thread zit te blocken. Roep je toevallig de get van de SwingWorker? Deze is namelijk wel blocking.

Waits if necessary for the computation to complete, and then retrieves its result.

Note: calling get on the Event Dispatch Thread blocks all events, including repaints, from being processed until this SwingWorker is complete.

When you want the SwingWorker to block on the Event Dispatch Thread we recommend that you use a modal dialog.

Idd! Goed gevonden, of eigenlijk slecht dat ik dat niet had gevonden :-). Maar nu snap ik niet wat nou het nut van die get is, je wilt toch dit gedrag voorkomen? Mijn downstream methods zijn weer afhankelijk van het resultaat dat ik via get krijg, dus hoe kunnen die nou de data krijgen?

[Domdo]

Ik zou in zo'n geval denk ik een Thread starten die wacht tot de get resultaat geeft en dan de rest van de functie's uitvoereten of in je swing-workers ook de rest van de methoden zetten.

[Nick_S]

Ik zou in zo'n geval de SwingWorker.done overriden en hierin de benodigde functies uitvoeren of een event sturen.

[ Voor 27% gewijzigd door Nick_S op 17-09-2009 14:21 ]

[Red devil]

Nick_S schreef op donderdag 17 september 2009 @ 14:21:
Ik zou in zo'n geval de SwingWorker.done overriden en hierin de benodigde functies uitvoeren of een event sturen.

Thanks! Alles wat ik er na moest heb ik in done() gepropt en voila, de gui thread was weer vrij en update alles :-) :-)

[Nick_S]

Red devil schreef op donderdag 17 september 2009 @ 15:03:
[...]


Thanks! Alles wat ik er na moest heb ik in done() gepropt en voila, de gui thread was weer vrij en update alles :-) :-)

Denk er aan dat je tijdens je done methode alweer op je GUI thread zit, dan is je app dus bevroren. Als je hier veel gaat doen, kan dit merkbaar zijn.