Hello,
I have a SwingWorker thread with an IOBound task which is totally locking up the interface while it runs. Swapping out the normal workload for a counter loop has the same result. The SwingWorker looks basically like this:
public class BackupWorker extends SwingWorker<String, String> {
private static String uname = null;
private static String pass = null;
private static String filename = null;
static String status = null;
BackupWorker (String uname, String pass, String filename) {
this.uname = uname;
this.pass = pass;
this.filename = filename;
}
@Override
protected String doInBackground() throws Exception {
BackupObject bak = newBackupObject(uname,pass,filename);
return "Done!";
}
}
The code that kicks it off lives in a class that extends JFrame:
public void actionPerformed(ActionEvent event) {
String cmd = event.getActionCommand();
if (BACKUP.equals(cmd)) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
final StatusFrame statusFrame = new StatusFrame();
statusFrame.setVisible(true);
SwingUtilities.invokeLater(new Runnable() {
public void run () {
statusFrame.beginBackup(uname,pass,filename);
}
});
}
});
}
}
Here's the interesting part of StatusFrame:
public void beginBackup(final String uname, final String pass, final String filename) {
worker = new BackupWorker(uname, pass, filename);
worker.execute();
try {
System.out.println(worker.get());
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
}
}
}
So far as I can see, everything "long-running" is handled by the worker, and everything that touches the GUI on the EDT. Have I tangled things up somewhere, or am I expecting too much of SwingWorker?
