I read that all the code which constructs Swing components and handles Events must be run by the Event Dispatch Thread. I understand how this is accomplished by using the SwingUtilities.invokeLater() method. Consider the following code where the GUI initialization is done in the main method itself
public class GridBagLayoutTester extends JPanel implements ActionListener {
public GridBagLayoutTester() {
setLayout(new GridBagLayout());
GridBagConstraints gbc = new GridBagConstraints();
JButton button = new JButton("Testing");
gbc.fill = GridBagConstraints.HORIZONTAL;
gbc.anchor = GridBagConstraints.WEST;
gbc.gridx = 0;
gbc.gridy = 0;
gbc.gridwidth = 1;
button.addActionListener(this);
add(button, gbc);
}
public void actionPerformed(ActionEvent e) {
System.out.println("event handler code");
}
public static void main(String[] args) {
JFrame frame = new JFrame("GridBagLayoutDemo");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Container contentPane = frame.getContentPane();
contentPane.setLayout(new BorderLayout());
contentPane.add(new GridBagLayoutTester(), BorderLayout.CENTER);
frame.setSize(800, 600);
frame.pack();
frame.setVisible(true);
System.out.println("Exiting");
}
}
How is it that this code works perfectly ? We are constructing JFrame and calling a host of other methods in the main thread. I do not understand where exactly the EDT is coming into picture here (what code is it executing ?). The constructor of the GridBagLayoutTester class is also being called from the main method which means the EDT is not running it.
In short
When is the EDT being started ? (does the JVM start the EDT along with the main method if at all the EDT is started while running this code ?)
Does the event handler code for the button run on the EDT ?
The code works perfectly because you are constructing the frame in the main thread, before the EDT has an opportunity to interact with it. Technically, you shouldn't do this ever, but technically you can under this specific circumstance because you cannot interact with the JFrame until it becomes visible.
The main point to know is that Swing components are not thread safe. This means that they cannot be modified from more than one thread at the same time. This is solved by ensuring that all modifications come from the EDT.
The EDT is a thread that's dedicated to user interaction. Any events generated from the user are always run on the EDT. Any user interface updates run on the EDT. For example, when you call Component.repaint(), you can call this from any thread. This simply sets a flag to mark the component as needing a paint, and the EDT does it on its next cycle.
The EDT is started automatically and is tied quite closely into the system implementation. It is handled well within the JVM. Typically, it correlates to a single thread in the windowing system that handles user interaction. Of course, this is quite implementation-dependent. The nice thing is that you don't have to worry about this. You just have to know - if you interact with any Swing components, do it on the EDT.
Likewise, there is one other thing that's important. If you are going to do any long-duration processing or blocking for an external resource, and you are going to do it in response to an event generated by the user, you have to schedule this to run in its own thread off the EDT. If you fail to do this, you will cause the user interface to block while it waits for the long-duration processing to run. Excellent examples are loading from files, reading from a database, or interacting with the network. You can test to see if you are on the EDT (useful for creating neutral methods which can be called from any thread) with the SwingUtilities.isEventDispatchThread() method.
Here are two snippets of code which I use quite frequently when writing Swing programming dealing with the EDT:
void executeOffEDT() {
if (SwingUtilities.isEventDispatchThread()) {
Runnable r = new Runnable() {
#Override
public void run() {
OutsideClass.this.executeOffEDTInternal();
}
};
new Thread(r).start();
} else {
this.executeOffEDTInternal();
}
}
void executeOnEDT() {
if (SwingUtilities.isEventDispatchThread()) {
this.executeOnEDTInternal();
} else {
Runnable r = new Runnable() {
#Override
public void run() {
OutsideClass.this.executeOnEDTInternal();
}
};
SwingUtilities.invokeLater(r);
}
}
The Event Dispatch Thread, as it name implies, is called by Swing every time an event needs to be processed.
In the example you gave, the "Testing" button will automatically call the actionPerformed method when an action event needs to be processed. So, the content of your actionPerformed method will be invoked by the Event Dispatch Thread.
To answer your two final questions:
The EDT is started automatically when the Swing framework loads. You don't have to care about starting this thread, the JRE handles this task for you.
The event handler code is run by the EDT. All events your Swing interface generates are pooled and the EDT is responsible for executing them.
1) I don't know if in new JFrame or in setVisible but it initialize on demand and that's what the end of the main method (over the main process thread) doesn't terminate the process. the EDT was launched and is in a loop blocked waiting the next event.
2) Definitively. That loop receives from the OS the event, find the JButton and tells it that the event was fired. The button then calls the listeners. All that happens in the EDT.
You could review the Swing code that you call when you want to kill the process (or closing the main window) for looking where the EDT is terminated... that can give you a clue (I'll do it later! :)
EDT thread is started after that you firstly call setVisible(true); if it is not started already, ofc. Or if you call SwingUtilities.invokeAndWait() or SwingUtilities.invokeLater() methods.
See http://www.leepoint.net/JavaBasics/gui/gui-commentary/guicom-main-thread.html
Related
So I tried creating a frame to perform a Diashow, but for some reason, I can see the only an empty frame and after everything is done, I see the last picture. What I wanted to see was each picture with a ~1 second pause in between. I used revalidate() / repaint() the way I suppose it is working, but Im fairly certain that the problem is there, since I cant think of another reason.
I am only starting to learn Java.Swing, so any input is really welcome to improve my skills. As I already said, I assume that the problem lies with my usage of revalidate(), but I cant fix it alone with google..
As input to the class I use an array of BufferedImage,for which I want to create the diashow.
I also tried putting the images directly on my Container c instead of on the JPanel p, but it doenst work either way I intend it to work.
public class DiashowFrame extends JFrame {
Container c;
JPanel p;
public DiashowFrame(JFrame father,BufferedImage [] image) {
c= getContentPane();
c.setLayout(new FlowLayout());
p = new JPanel();
p.setLayout(new FlowLayout());
p.setSize(500,500);
c.add(p);
setSize(500,500);
setLocation(father.getX(),father.getY());
setVisible(true);
dia(p,image);
}
public static void dia(JPanel p,BufferedImage[] image) {
JLabel def= new JLabel(new ImageIcon(image[0]));
p.add(def);
//c.repaint();
p.revalidate();
for(int x=1;x<image.length;x++) {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
//p.removeAll();
//p.revalidate();
Image imager = image[x].getScaledInstance(500, 500, 100);
def = new JLabel(new ImageIcon(imager));
p.add(def);
p.revalidate();
//p.repaint();
}
}
}
Start by taking a look at Concurrency in Swing.
Swing, like most GUI frameworks, is single threaded AND not thread safe.
This means that any long running or blocking operation executed from within the Event Dispatching Thread will prevent the EDT from processing the Event Queue and update the UI in anyway.
While you could use a Thread to offload the wait time to a second thread, Swing is NOT thread safe, meaning you should never update/modify the UI directly or indirectly from outside the context of the EDT.
The simplest solution in your case is to simply use a Swing Timer. This allows you to specify a delay between updates (and if it's repeating or not), which is executed off the EDT, but when triggered, is notified within the context of the EDT, making easy and safe to use with Swing.
The Timer acts as a pseudo loop, each trigger of the Timer representing the next iteration
See How to use Swing Timers for more details
public class TestFrame extends JFrame
{
public TestFrame()
{
setBounds(10, 10, 500, 500);
setLocationRelativeTo(null);
setDefaultCloseOperation(3);
}
public static void main(String[] args) throws InterruptedException
{
TestFrame tf = new TestFrame();
tf.add(new JButton("test1"));
tf.setVisible(true);
Thread.sleep(2000);
tf.getContentPane().removeAll();
tf.add(new JButton("test2"));
System.out.print("Show test");
}
}
I want the program show JButton("test2") after 2 seconds.
Then I add thread.sleep(2000) after test1.
But I don't know why the program stops at showing the test1 JButton,
not showing test2 JButton and the "show test" message can sucess print out
Short answer, don't.
Swing is a single threaded framework, this means that any thing that blocks the Event Dispatching Thread will prevent it from updating the UI or processing any new events (making your UI look like it's hung, cause it has).
Sure, you could use a Thread, but Swing is also not thread safe. This means that ALL modifications to the UI MUST be made from within the context of the Event Dispatching Thread. While there are ways to overcome this, the easiest way is to simply use a Swing Timer.
Take a closer look at How to use Swing Timers and Concurrency in Swing for more details
You should also take a look at Initial Threads.
When updating the UI, it may be required to call revaldiate and repaint after you have added the new components to force the UI to update to re-layout it's contents.
I'm creating a board game using a GUI and JFrames/JPanels where you can play against the computer. I have a method called showPieces() which updates board GUI by changing the image icons on an array of buttons (which are laid out in a grid format). Once the icons have been updated the revalidate() and repaint() methods to update the GUI.
The showPieces() method has a parameter that needs to be passed to it every time it is called.
The main issue I'm having is I want the human to make a move, update the GUI, wait 1 second, the computer makes it's move and then loop until someone wins.
My basic code is the following:
do{
human.makeMove();
gui.showPieces(data);
try {
Thread.sleep(1000);
} catch(InterruptedException ex) {
Thread.currentThread().interrupt();
}
computer.makeMove()
gui.showPieces(data);
}while(playing);
This cause the issue where when the human player makes their move, the GUI will freeze for one second and then after the delay, both moves are made at the same time.
I hope it makes sense, but I'm a novice with Java and may have to look more into threading as I don't understand it well enough.
Thread.sleep() is done on the Event Dispatch Thread which will lock the GUI.
So If you need to wait for a specific amount of time, don't sleep in the event dispatch thread. Instead, use a timer.
int delay = 1000; //milliseconds
ActionListener taskPerformer = new ActionListener() {
public void actionPerformed(ActionEvent evt) {
//...Perform a task...
}
};
new Timer(delay, taskPerformer).start();
As with most all similar Swing questions, you're putting your entire Swing GUI to sleep by calling Thread.sleep(...) on the GUI's event thread (the EDT or Event Dispatch Thread), and when during this period the GUI will not be able to update its images or interact with the user whatsoever. The solution here is not to use Thread.sleep(...) but rather to use a Swing Timer to cause your 1 second delay.
Swing Timer Tutorial.
I have the following Java Code which adds a JRadioButton to a JPanel and handles its mouse click event
JRadioButton offline = new JRadioButton();
offline.setText("Offline Mode");
modePanel.add(offline);
modePanel.setLayout(new GridLayout(2,1));
offline.addMouseListener(new java.awt.event.MouseAdapter() {
public void mouseClicked(java.awt.event.MouseEvent evt) {
offlineClicked(evt);
}
});
The function offlineClicked takes roughly around 1 min to be executed completely.
And until its execution is completed no other actions performed are handled.
All actions performed thereafter seem to go to a Eventqueue and handled FIFO when the offlineClicked has completed execution.
Due to this the UI seems to have gone into a hung state.
What can be done to make swing handle events concurrently and not wait till the last is executed completely.
When the mouselistener event is fired it runs on the event dispatch Thread (the swing gui thead that redraws the screen). If you put logic code in the gui thread then your gui would freeze until the logic completes and returns the gui thread back to swing. You can use swingworker or another option is to simply start a new thread and let the gui thread return so it can let other gui events process. In the new thread do your time consuming logic, it's running off of the event loop so swing won't freeze as it's running async. You MUST run all swing code on the dispatch thread so when the logic is done since you are no longer on the dispatch thread you have to add it to the event queue.
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
// you can now safely use swing components
new frame.setVisible(true);
}
} );
I have tried a lot, but can't seem to get it to work.
I was told to use EDT with the following example.
SwingUtilities.invokeLater(new Runnable() {
public void run() {
// Modify the GUI here
}
});
I have read on this topic a lot and still don't understand. I get what a thread is, but the .invokeLater still makes no sense to me. Honestly if you can explain in detail this it would be a big help!
Goal of Program: To get the randomly generated key that is constantly created every second to update itself afterward in the GUI.
So there is an EDT (Event Dispatch Thread). All actions that appear on your screen are executed by the EDT. There is only one EDT per Swing application.
You are in some arbitrary thread and you want to update the GUI through that thread? Well like I said there is only one EDT for each swing application, so you have to tell that EDT to display the label (or whatever context you want).
The idea here, is you push this Runnable onto a queue that the EDT pulls from. Eventually, your runnable will be processed by the EDT when all other actions before it are completed.
I recommend you get the book Filthy Rich Clients. There's a chapter where they explain Swing's threading model to great detail.
Basically in Swing, any code that modifies the GUI should be executed in the Event Dispatcher Thread. The SwingUtilities class that you are using there provides you with an easy way to post events to the event queue that is then dispatched by the EDT. That's what the invokeLater method does, it takes a new Runnable() as argument which is ultimately executed on the EDT.
From the book:
The invokeLater() implementation takes
care of creating and queuing a special
event that contains the Runnable. This
event is processed on the EDT in the
order it was received, just like any
other event. When its time comes, it
is dispatched by running the
Runnable’s run() method.
This is a pretty common element of all GUI programming. You have one thread that handles drawing the GUI, getting input, and running callbacks. If another thread tries to change the GUI related objects, it will conflict with the GUI thread. Say, for example, it was half way through drawing something and you change the color from a different thread.
All invokeLater does is queue up something for the GUI thread to run. By "later" it's really runs almost instantly but the current thread doesn't have to wait for it. The GUI thread may be doing a draw or waiting for a callback to return which would delay executing the code you gave it.
Needs to be a member so we can change it and still use it from an inner class
protected long secret=0;
... this needs to be in your code somewhere it'll get run...
JFrame f = new JFrame("foo");
new Thread(){
public void run() {
for(;;){
try {
sleep(1000);
} catch Interrupted (Exception ix){
return;
}
// TODO update your secret key here
// please don't use random()
SwingUtilities.invokeLater(new Runnable() {
public void run() {
f.setTitle("secret "+x);
}
});
}
}
}).start();
....
Only ever update Swing from the EDT so that it paints properly.
When you are in the EDT ( running code in an event handler) you can call paintImmediately() if you really must.
If you're all looking to do is update the UI on a known schedule, try something like the following. This assumes that a JFrame is the component you wish to update every 1 second.
private static final int WAIT_LENGTH = 1000; // 1 second
private JFrame frame = new JFrame();
// Thread will update the UI (via updateUI() call) about every 1 second
class UIUpdater extends Thread {
#Override
void run() {
while (true) {
try {
// Update variables here
}
catch (Exception e) {
System.out.println("Error: " + e);
}
finally {
frame.repaint();
Thread.sleep(WAIT_LENGTH);
}
}
}
}
To start this thread:
UIUpdater t = new UIUpdater();
t.start();