I've been coding a simulation that has a JFrame GUI for parameter input, and a separate JFrame that runs an animation of the simulation.
I update the animation together with the simulation, so the call to repaint comes from the function runsimulation()
I have added an EXIT_ON_CLOSE for my main GUI frame, and while the animation is running I can close the frame and it doesn't pop up again, but I want to know if it is possible to shut down the simulation thread when I close the animation frame.
Because currently when I close the frame the simulation keeps on running in the background and finishes properly, but I'd like the close event on the animation frame to be a "cancel simulation" as well.
You have two choices here. One option is to make the running thread into a "Daemon" thread. This means that the thread will not keep the program running, so if you close the JFrame and exit the application it will terminate immediately.
Be aware that the long running thread could potentially get terminated abruptly and in the middle of processing things though.
The (probably better) way is to call interrupt() on the thread and have the thread check isInterrupted() at regular intervals and exit cleanly if the flag is set.
Related
I am building a game and I am trying to create "New game" button.
In the game I have thread that delays computer's move so I can see it step by step by using thread.sleep.
My problem is that I can't make a New Game until this thread is over.
If I manually stop it, I will get InterruptedException.
What can I do in order to do it?
My game is placed on JPanel which is placed on JFrame.
I tought that if I dispose the JFrame and create a new one, it will destroy the JPanel and all it's content and create a new one all over. but it's not working either.
Any suggestions??
Thanks in advanced,
Ron.
For stopping a Thread, see: https://stackoverflow.com/a/8581317/1178781
The InterruptedException is thrown if you stop a thread while it is sleeping. Just wrap the sleep call in a try...catch (with the catch doing nothing) if you do not want to handle this exception.
See the Java API: http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#sleep(long)
Also see: How to programmatically close a JFrame
I've been spending a great deal of time trying to understand this. I created a JApplet that used Thread.sleep() in a loop to animate the applet. But when I tried to run the Applet the screen stayed blank. When I draw the animations in a separate thread and call repaint, the applet works perfectly. I've seen many explanations of why this happens but none have been very comprehensive.
What thread calls the paint method? And why can't that thread partially draw on the canvas, pause, then continue drawing? I've noticed that some Thread.sleep() calls work as expected, particularly when they are not in a loop.
UI needs to be repainted and this happens on UI thread.
Therefore you should not seize control of the UI thread - it seems that you are doing just this (animation loop with .sleep()).
You should return control of the UI thread (exit the function that you are in) so that it can be repainted.
Take a look at Swing Painting and SwingWorker to understand how to run a background thread to do some work and then update UI on UI thread.
I'm using the java swing library to develop a board game called DAO.
The problem is that after the human player makes its move, by clicking on the JButton with the piece image that he wants to play, I call the computer AI routine but inside the mouse event function. By doing this only when the function returns, the computer ends its turn, do the JButtons refresh their Images (setIcon comes in).
I'd like to know how can I force the JButtons to change their image at the moment they are clicked and not only when the mouse event function ends (as I need to handle data inside it).
I've tried all of this
myButtons[i][j].setIcon(xIcon);
myButtons[i][j].revalidate();
myButtons[i][j].repaint();
myButtons[i][j].validate();
None worked.
Thx in advance
You may want to try putting the action performed upon clicking the JButton into a Swing worker. This will allow the task to go on in the background, while the user can still click other buttons, etc.
See http://java.sun.com/docs/books/tutorial/uiswing/concurrency/simple.html.
There is a single thread used for all Swing activity.
Here's the process.
One event appears on the event queue
it is pulled from the queue and executed by The AWT Thread
Any new events created while this is executing are placed on the queue to be held until the currently running AWT event returns.
The event executing returns and the next event on the queue is dequeued and executed.
This means that if you need to do anything that takes more than, say 1/100 of a second or so, you shouldn't do it any thread started from a swing event. Instead, spawn your own thread and return the swing thread to the system so the GUI can be updated.
Now, your thread MUST NOT update any GUI objects! If you need to update a GUI object, use invokeLater to place your code back on the AWT thread.
New Java programmers not conforming to this rule and executing tasks on the AWT thread is almost certainly the biggest reason people think Java is slow.
I've built a form with Netbeans's visual editor. When I press one of the buttons it should do the following :
set it to disabled
perform a task that takes some time
when the task finishes the button will be enabled again
However, the following happens:
the button remains in a pressed state until the task finishes
when the task finishes, the enabling/disabling of buttons will be very fast (they will happen, but you won't notice them)
This behaviour is not something I want. I tried using repaint on the JButton, on the JFrame and even on the JPanel containing the button, but I can't seem to get it to do what I want. Some hints?
When you do work in a button callback, you are stalling the GUI painting thread until it completes.
What you need to do is spawn a thread to do the long running task, and then have that thread use SwingUtilities.invokeLater() to update the UI when it completes. Not using invokeLater is not thread safe, and is generally bad mojo.
A basic example is:
button.setEnabled(false);
new Thread(new Runnable() {
public void run() {
// Do heavy lifting here
SwingUtilies.invokeLater(new Runnable() {
public void run() {
button.setEnabled(true);
}
});
}
}).start();
When you do things in a button callback, you are essentially stalling the gui painting thread - not just for the button, but for ANY gui painting. (Try covering the interface with another window and then exposing it again - it won't repaint until the task is finished!)
What you need to do is spawn a thread to do the long running task, and then have that thread use SwingUtilities.invokeLater() to do the enabling of the button. invokeLater forces the button enable to happen in the gui painting thread.
You may want to set a busy cursor or otherwise lock the interface while the long-running thread is operating.
The Concurrency in Swing tutorial from Sun is well worth a read. Excellent explanation and background reading, including the event dispatching thread, using worker threads, etc
You need to do the task that takes some time in a different thread.
The reason the button is blocking is because the work is being done in the same thread that draws the button. Once the work is done the button can do the rest of what you tell it to.
If you use a different thread the thread will go do the task while the drawing code can continue drawing the form.
I have a login frame that i have to wait for from another thread. Upon successful login frame disposes itself. And i want to pop up the main frame for the application. Right now i am watching a boolean value to determine when to fire up the main frame. What is the correct way of doing this? Watching a boolean value just does not feel elegant.
If you have Java 5 or later available, you could use a CountDownLatch. For example, assuming the main frame is in control initially, have the main frame create the CountDownLatch with a count down of 1 and pass this latch to the login frame. Then have the main frame wait for the latch to become 0:
CountDownLatch loginSignal = new CountDownLatch(1);
... // Initialize login frame, giving it loginSignal
... // execute login frame in another Thread
// This await() will block until we are logged in:
loginSignal.await();
Have the login frame, when done, decrement the Latch:
loginSignal.countDown();
Ensure that there is no way for your login frame to exit where it forgets to decrement the latch! As soon as the CountDownLatch reaches 0, the main frame becomes runnable.
You could also use a Semaphore or Condition (or any of a few other choices from java.util.concurrent), but for this purpose, a CountDownLatch seems easier to use.
What you really must understand with dealing with Swing (and in fact AWT), is that you need to keep all interaction with the components of the AWT Event Dispatch Thread (EDT).
So, do the login off the EDT. Use a new Thread, or better a java.util.concurrent.ExecutorService. When you discover that you have been logged in, use java.awt.EventQueue.invokeLater to get back onto the EDT. Anonymous inner class are great for capturing context and, despite their horrendously verbose syntax, making the code shorter.