You are calling doInBackground() directly from your code, something that is akin to calling run() directly in a runnable. This means that your code is not in fact running on a background thread, and so you are likely clobbering the event thread with long running code, preventing the Swing GUI, and your progress bar, from … Read more
Several things: There are four rules to follow with SwingWorker. You can refer to this diagram: . So, this code: @Override public String doInBackground() { //download here label.setText(“test”); violates that rule. Your label.setText() should be moved to the constructor. To send “updates” to Swing components (like your progress bar) you want to use the process() … Read more
You need to keep a reference to your SwingWorker, then you use that reference to cancel the worker thread. MySwingWorker myWorker = new MySwingWorkerClass(args).execute(); button.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { // Stop the swing worker thread myWorker.cancel(true); } }); Here is a full example: public class WorkerDemo extends JFrame { private boolean isStarted … Read more
The setProgress() API notes: “For performance purposes all these invocations are coalesced into one invocation with the last invocation argument only.” Adding Thread.sleep(1) simply defers the coalescence; invoking println() introduces a comparable delay. Take heart that your file system is so fast; I would be reluctant to introduce an artificial delay. As a concrete example … Read more
SwingWorker is a lot simpler to use them it might seem. Basically, you need to make a few basic decisions about what you want to achieve. Do you want to return periodically updates while the process is running or Do you want to return a result of the process…or both? Do you want to provide … Read more
Because your background thread is devoted entirely to watching, take() is the right choice. It effectively hides the platform dependent implementation, which may either forward or poll. One of the poll() methods would be appropriate if, for example, your background thread also needed to examine other queues in series with the WatchService. Addendum: Because the … Read more
SwingWorker supports PropertyChange events, that is, you can listener to when the SwingWorker changes state or updates it’s progress…yes, SwingWorker even supports progress notification, for example This means you could set up a PropertyChangeListener to monitor changes to the progress and state properties and take appropriate actions… A worker that simple sets progress updates… public … Read more
Consider using a JList for the right panel to take advantage of the flexible layout options and selection handling, as shown here and below. import java.awt.Component; import java.awt.Dimension; import java.awt.EventQueue; import java.awt.Graphics; import java.awt.Graphics2D; import java.awt.GridLayout; import java.awt.RenderingHints; import java.awt.image.BufferedImage; import javax.swing.BorderFactory; import javax.swing.DefaultListCellRenderer; import javax.swing.DefaultListModel; import javax.swing.Icon; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JList; import … Read more
The main problem you’re having is you’re trying to perform blocking actions in the Event Dispatching Thread. This will prevent the UI from been updated as repaint requests are not reaching the repaint manager until AFTER you’ve finished. To over come this, you’re going to need to off load the blocking work (ie the back … Read more
if I add Thread.sleep(…), it does work, though, it throws a InterruptedException The code that apparently produces the exception (copied from OP’s edit): while (!isCancelled()) { counter %= arrNames.length; // System.out.format(“Counter : %d%n”, counter); publish(arrNames[counter]); try { Thread.sleep(30); // throws } catch (InterruptedException ie) { ie.printStackTrace(); } counter++; } The reason, though, is the code … Read more