I'm having a problem where my Swing GUI components aren't updating for me while the program is busy. I'm creating an image editor and while heavy processing is happening, I try to change a "status" label while its working to give the user an idea of whats going on. The label won't update until after the processing is finished though.
How can I update the label IMMEDIATELY instead of having to wait? My labels are all on a JPanel by the way.
My label isn't set until after the for loop and the following method finishes.
labelStatus.setText("Converting RGB data to base 36...");
for (int i = 0; i < imageColors.length; i++) {
for (int j = 0; j < imageColors[0].length; j++) {
//writer.append(Integer.toString(Math.abs(imageColors[i][j]), 36));
b36Colors[i][j] = (Integer.toString(Math.abs(imageColors[i][j]), 36));
}
}
String[][] compressedColors = buildDictionary(b36Colors);//CORRECTLY COUNTS COLORS
I'm having a problem where my Swing GUI components aren't updating for me while the program is busy.
That is because you are executing a long running task on the Event Dispatch Thread (EDT) and the GUI can't repaint itself until the task finishes executing.
You need to execute the long running task in a separate Thread or a SwingWorker (for a better solution). Read the section from the Swing tutorial on Concurrency for more information about the EDT and examples of using a SwingWorker to prevent this problem.
You can do something like this, not the best but it can give you some idea
Create a thread dispatcher class and call it from main class
public class ThreadDispatcher implements Runnable {
public ThreadDispatcher() {
}
public void run() {
//call the method related heavy process here
}
}
It may be like this in your main class
Thread thread = new Thread(new ThreadDispatcher());
thread.start();
sleep(100);
catch the InterruptedException ex.
And check the Java thread examples.
Related
I am adding a feature to a program to save some content to file. The progress is shown by a progress bar (in its own JFrame), but the progress bar is only being displayed on the last value it reads. I have a global being updated by the main thread, that represents the % of work completed, and the other thread reads this global and updates the progress bar accordingly.
Right now when it runs, the JFrame is empty, then activity completes, then the progress bar shows itself with complete amount. How do i make it update the progress as it goes along (and show the JProgressbar from the start)? Here is my code:
public class GenomeAnnotator{
private JProgressBar csvProgressBar;
private JFrame csvSaveLoadFrame; //for the progress bar
private Container csvCon;
private double csvPercentSaved; //% of work completed
public JFrame m_frame; //main program frame
....
public static void main(String[] args){
...
showGUI();
...
}
public void showGUI(){
...
JMenu file = new JMenu("File");
JMenu exptann = new JMenu("Export annotation..);
JMenuItem exptcsv = newJMenuItem("CSV format");
exptcsv.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
..determine output file + checks...
System.out.println("Writing to .csv file......");
csvSaveLoadFrame = new JFrame("Saving to csv file..");
csvProgressBar =new JProgressBar(0,100);
csvSaveLoadFrame.setSize(300,100);
csvCon = csvSaveLoadFrame.getContentPane();
csvCon.setLayout(null);
csvProgressBar.setBounds(10,10,280,20);
csvCon.add(csvProgressBar);
csvSaveLoadFrame.setResizable(false);
csvSaveLoadFrame.setVisible(true);
ORF [] ora= orfPanel.getAcceptedOrfs();
int val;
double toload = blastData.size() + ora.length; //how much work
double loaded=0.0; //how much work completed
/*Thread that will read % value from global and update prog. bar*/
Thread progressBarMover = new Thread() {
#Override
public void run() {
int previous=0;
while(csvPercentSaved<100){
csvProgressBar.setValue((int)csvPercentSaved);
//tried putting a sleep() in here when testing
//values from global is read successfully
}
}
System.out.println("Thread done!");
csvPercentSaved = 0; //reset value when done
csvSaveLoadFrame.setVisible(false);
}
};
progressBarMover.start();
for (int k=0; k<blastData.size(); k++) {
..do output work...
loaded+=1; //update % values
csvPercentSaved = (loaded/toload)*100;
val = (int)csvPercentSaved;
System.out.println("main complete "+val+"%");
}
for (int k=0; k<ora.length; k++) {
...do more ouput work...
loaded+=1;
csvPercentSaved = (loaded/toload)*100; //update % value
val = (int)csvPercentSaved;
System.out.println("main complete "+val+"%");
}
System.out.println("Output file finished!");
csvPercentSaved = 100;
}
});
exptann.add(exptcsv);
file.add(exptann);
}
EDIT
found solution here:
https://weblogs.java.net/blog/mkarg/archive/2010/01/03/did-you-know-swingworker-can-send-progress-status
Several issues there:
Most most important (and I missed this initially!), you're not doing your long running code within the background thread but rather within the Swing event thread, the EDT. I am meaning these two for loops: A) for (int k=0; k<blastData.size(); k++) {...} and B) for (int k=0; k<ora.length; k++) {...} which looks to be the code where you're loading or saving information. This will freeze your GUI right up.
Also important, you're doing Swing calls from within a background thread, including setting the progress bar's value and setting a JFrame's visiblity, something that you never want to do, and that mostly negates the benefits of using the background thread in the first place.
In other words, you're doing all your Swing threading work exactly backwards -- making Swing calls from the background thread and running the long process in the event thread.
Instead, do the opposite -- do all the long-running work in a background thread and make all of the non-thread-safe Swing calls on the EDT.
One way to do this is to use a SwingWorker, do your loading and saving from within its doInBackground(...) method
and set its progress field as progress is being made..
You would then monitor the worker's progress field in a PropertyChangeListener, this being done on the EDT, and then use this to set your progress bar's value.
Or if you have to use your own background thread, then
Have the inner class implement Runnable, not extend Thread
If you make Swing calls from within your background thread, then wrap these calls in a Runnable and queue them onto the Swing event thread via SwingUtilities.invokeLater(yourRunnable)
More minor issues:
You should not be using null layouts and absolute positioning but rather use layout managers. While null layouts and setBounds() might seem to Swing newbies like the easiest and best way to create complex GUI's, the more Swing GUI'S you create the more serious difficulties you will run into when using them. They won't resize your components when the GUI resizes, they are a royal witch to enhance or maintain, they fail completely when placed in scrollpanes, they look gawd-awful when viewed on all platforms or screen resolutions that are different from the original one.
Your secondary dialog window should be a JDialog, and probably a modal JDialog, not another JFrame. You're not creating and showing a new stand-alone program, but rather are displaying a dialog window off of the main GUI window. If you want the main GUI window non-functioning while the dialog is displayed, then the modal JDialog is the way to go, as it works just like a JOptionPane (which is a form of a modal JDialog), and makes the calling window non-functional while its visible.
For some of my code examples:
How do I make my SwingWorker example work properly?
For a lot more of my examples
I have a JButton and have added an ActionListener to it. I also have a SimulationPanel class which extends JPanel and have an instance of it named simulationPanel. Both are added to a JFrame. Within in the actionPerformed method of the ActionListener I call simulationPanel.startSimulation().
class StartButtonListener implements ActionListener{
#Override
public void actionPerformed(ActionEvent arg0) {
if(mode == MODE_DEFAULT){
mode = MODE_SIMULATING;
startButton.setText("Stop Simulation");
simulationPanel.startSimulation();
} else if(mode == MODE_SIMULATING){
mode = MODE_DEFAULT;
startButton.setText("Start Simulation");
simulationPanel.stopSimulation();
}
}
}
The stopSimulation() method sets running to false.
public void startSimulation() {
running = true;
long time = System.currentTimeMillis();
long time2 = System.currentTimeMillis();
while(running){
time = System.currentTimeMillis();
if(time - time2 > 1000/60){
for(int i = 0; i < planets.size(); i++) {
planets.get(i).setLocation(planets.get(i).getNewLocation());
}
this.paintImmediately(0, 0, 950, 680);
time2 = System.currentTimeMillis();
}
}
}
This sets the new location of my planets and repaints the screen every 60th of a second.
The problem is that once it has entered the while(running) loop the ActionListener no longer responds to the button being pressed and therefore stopSimulation() can't be called. How would I go about creating a new thread that makes the button able to respond while simulation is running?
The entire program
Swing is a single threaded environment, if you block the Event Dispatching Thread, then it can't process the Event Queue, which involves processing user input and reaping events.
When you need to execute long running tasks, you should offload the task to another thread.
Just remember, Swing is also not thread safe, this means that you should NEVER create or modify the UI from outside the context of the Event Dispatching Thread.
There are tools you can use to make your life easier in this respect.
You could use a SwingWorker, which would allow you to run the long running/blocking tasks in the background, but use the publish/process methods to send updates to the UI which does not violate the single thread rules of Swing
You could use a Swing Timer, which would allow you schedule regular callbacks which are executed within the context of the EDT, making it safe to update the UI from within
You could use a plain old Thread and use SwingUtilities.invokeLater to synchronise updates with the EDT, but I'm not a fan of this approach is its a pain to pass stateful information through
Yes of course, because your start simulation is blocking your main thread.
I suggest you use Swing Timer http://docs.oracle.com/javase/tutorial/uiswing/misc/timer.html
This question already has an answer here:
MVP, JFrame, JDialog : GUI is freezing
(1 answer)
Closed 8 years ago.
i'm trying to update Swing JSLable text before processing loop, but it's not updating:
public void actionPerformed(ActionEvent event)
{
title.setText("Ready"); // Initialize display
if (source == uploadButton) {
int returnVal = fc.showOpenDialog(UserInterface.this);
if (returnVal == JFileChooser.APPROVE_OPTION) {
File[] files = fc.getSelectedFiles();
if (files.length < 2) {
title.setText("<html>Text1</html>"); // Is shown
} else {
title.setText("<html>Text2</html>"); // Not displaying, feels like UI is locked here
for (int i = 0; i < files.length; i++) {
filesUploaded.add(uploadFile(files[i]));
}
Images imgs = new Images();
imgs.processImages(filesUploaded); // Some processing loop inside, takes around 0.5~1s
title.setText("Completed"); // displayed corectly.
}
}
}
}
So basically i wish to have sequence:
Ready
Text2
Completed
but i get this sequence (with missing Text2 output):
Ready
Completed
The GUI thread is blocked, you should wrap this part of code into SwingUtilities.invokeLater:
SwingUtilities.invokeLater(new Runnable() {
for (int i = 0; i < files.length; i++) {
filesUploaded.add(uploadFile(files[i]));
}
Images imgs = new Images();
imgs.processImages(filesUploaded); // Some processing loop inside, takes around 0.5~1s
title.setText("Completed"); // displayed corectly.
});
BTW, C-style for loops are not appreciated in Java, you should use "enhanced for" construction:
for (File file: files)
filesUploaded.add (files);
Or even
filesUploaded.addAll(Arrays.asList(files))
That is ok because you block the GUI thread (action is performed in that thread) and it won't update before you exit the method.
Look for "block gui thread java". You'll find that often happens in actionPerformed.
Swing works on Single Threaded Model and that thread of Swing application is called EDT (EventDispatchThread) Its always suggested not to do any heavy processing on this thread because it will block UI thread and your UI will become un-responsive for that duration. I would suggest moving the file upload part in a separate thread to keep your UI responsive.
And use SwingUtilities.invokeLater to schedule any UI related work on EDT from this separate thread.
Another approach may be to use SwingWorker
Use SwingWorker or Foxtrot to implement your long running Task. Your long running task blocks the EDT (Event Dispatcher Thread - main Swing thread) and the Repaint event which must come after event processing cannot be executed.
You should put those HTML tags somewhere else, since it confuses swing when you put text outside of HTML. E.g. You should put the opening tag before the ready word and the closing tag after the completed string. You should also know that the setText method overwrites the text in the element. You should use:
setText(object.getText()+"Text");
For example
title.setText("<HTML>Ready");
//...
title.setText(title.getText()+"Text2");
//...
title.setText(title.getText()+"Completed</HTML>");
Please note that the actionPerformed() method is called by the event dispatch thread which manages the Graphical User Interface and you are using it for a lengthy task. This freezes the GUI since the EDT is not avaliable for updating the GUI. Use a different thread instead:
Thread t=new Thread(new Runnable(){
public void run(){
<your code here>
}
});
Also if you are accessing swing, Java recommends doing it on the event thread, like when you are calling setText() or something similar:
SwingUtilities.invokeLater(new Runnable(){
public void run(){
<your code to access swing>
}
});
i have here a strange behaviour of my graphical user interface.
At first here a piece of code:
/**
*
*/
#Override
protected Void doInBackground() throws Exception {
final ModelGameState actualGameState = controller.getActualGameState();
final ModelCoinState actualCoinState = (actualGameState.getPlayersTurn() == ModelConstants.PLAYER_ONE_ID? actualGameState.getCoinsPlayerOne() : actualGameState.getCoinsPlayerTwo());
final List<ModelCoinState> temp = MoveCalculator.getMoves(actualCoinState, this.cellID);
final CountDownLatch lock = new CountDownLatch(temp.size());
int time = 500;
for(int i = 0; i < temp.size(); i++) {
final int index = i;
Timer timer = new Timer(time, new ActionListener() {
public void actionPerformed(ActionEvent e) {
if(actualGameState.getPlayersTurn() == ModelConstants.PLAYER_ONE_ID) {
actualGameState.setCoinsPlayerOne(temp.get(index));
} else {
actualGameState.setCoinsPlayerTwo(temp.get(index));
}
controller.setActualGameState(new ModelGameState(actualGameState));
lock.countDown();
}
});
timer.setRepeats(false);
timer.start();
time += 500;
}
lock.await();
return null;
}
at second here my gui:
and here my problem: everytime lock.await is called my screen
looks like that:
As you can see, behind each of my circles the top left corner
of my gui is shown everytime lock.await() is called (At least i
think it is when lock.await()is called because when i delete lock.await()
i cant see the whole animation of my gui but i also cant
see this strange behaviour and that behaviour appears always
when the program is through all code of doInBackground().
What causes this strange behaviour?
not an answer only disagree with, my comments against, no reviews, not tried your code, apologize me that there are any reason, maybe my bad
doInBackground() is bridge between AWT/Swing EDT and Workers Thread(s), by default never notified EDT
process, publish, setProgress and done() notify EDT
then Swing Timer inside doInBackground() is against all intentions, why was SwingWorker implemented in official APIs, there is place to execute long running, hard or non_safe code
again SwingWorker is designated as bridge between AWT/Swing and Workers Thread(s)
_____________________________
there are two ways
use CountDownLatch with invokeLater() or Swing Timer. don't mix that together nor from SwingWorker
use CountDownLatch, util.Timer, SheduledExecutor with notify EDT by wrap (only relevant, only output, methods will be repainted on the screen) Swing methods to the invokeLater()
use only Swing Timer (non_accurate on hour period)
I am using java.
I have a click event that adds "squares" to a container, in a loop. I want each square to show up RIGHT when it is added. I tried running the 'adding of the squares' in a separate thread, but it is not working.
Here is some code I use for 'public class GuiController implements ActionListener, MouseListener':
#Override
public void mouseClicked(MouseEvent e)
{
//createBoardPane();
new Thread
(
new Runnable()
{
public void run()
{
showAnimation();
}
}
).start();
}
public void showAnimation()
{
for(int i = 0; i < model.getAnimationList().size(); i++)
{
String coord = model.getAnimationList().get(i);
int x = Integer.parseInt(coord.substring(0, coord.indexOf(',')));
int y = Integer.parseInt(coord.substring(coord.indexOf(',') + 1, coord.length() - 2));
boolean shouldPlacePiece = (coord.charAt(coord.length() - 1) == 'p');
if(shouldPlacePiece)
{
model.getView().getBoardPane().getComponent(x + (y * model.getBoardSize())).setBackground(Color.BLACK);
}
else
{
model.getView().getBoardPane().getComponent(x + (y * model.getBoardSize())).setBackground(Color.WHITE);
}
model.getView().getBoardPane().repaint();
long time = System.currentTimeMillis();
while((System.currentTimeMillis() - time) < 250)
{
// wait loop
}
}
}
any help is appreciated!
Creating a separate Thread to run for this longish-running task was an excellent idea - unless you want to lock-up interactions with your GUI while doing your animation.
Now, Swing GUI objects are not Thread safe (with few exceptions), so you cannot work with them from a thread other than Swing's Event Dispatch Loop's thread. So take all the GUI update code in your for-loop, and wrap it with a new Runnable (yes, another one).
Then call SwingUtilities.invokeLater(Runnable doRun) with that Runnable on each iteration of the loop.
Your GUI update code will then be scheduled to run ASAP on the Event Dispatch Loop, which will occur while your worker thread goes to sleep (do you have anything against Thread.sleep?).
Alternative: Use SwingWorker instead of Thread
SwingWorker will create and manage a new the Thread for you, and publish data that it (SwingWorker) will cause to be run on the Event Dispatch Loop's thread. You'll override doInBackground with your code. Call publish with parameters to push across into the Event Dispatch Thread. Override process with code to process those parameters and update your GUI.
On gotcha with SwingWorker is that it accumulates published events over a period of about 33 milliseconds. If you're publishing more frequent than that you may get all your events bunched together every 33 milliseconds or so. In you case, 250 milliseconds between updates shouldn't be a problem.