Why actionPerform() run in Event Dispatch Thread but componentAdded() is not? - java

I have Ex1 below:
main(String args[]) {
JFrame frame = new JFrame("Title");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JButton button = new JButton("Press Here");
ContainerListener container = new ContainerAdapter() {
public void componentAdded(final ContainerEvent e) {
System.out.println("On the event thread? : " +
EventQueue.isDispatchThread());
}
};
frame.getContentPane().addContainerListener(container);
frame.add(button, BorderLayout.CENTER);
frame.setSize(200, 200);
System.out.println("I'm about to be realized: " +
EventQueue.isDispatchThread());
frame.setVisible(true);
}
My result is: On the event thread? : FALSE | I'm about to be realized: false
Other Ex2:
public class GridBagLayoutTester
extends JPanel implements ActionListener{
public GridBagLayoutTester() {
setLayout(new GridBagLayout());
GridBagConstraints gbc = new GridBagConstraints();
JButton button = new JButton("Testing");
// do something...
button.addActionListener(this);
add(button, gbc);
}
public void actionPerformed(ActionEvent e) {
System.out.println("On the event thread? : " +
EventQueue.isDispatchThread());
}
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("I'm about to be realized: " +
EventQueue.isDispatchThread());
}
}
result is: I'm about to be realized: false | On the event thread? : TRUE
My question is why Ex1- componentAdded() run in Intial Thread, but Ex2- actionPerformed() run in EDT ?

Few facts about GUI applications in Java:
- In Java GUI applications the main() method is short-lived, after scheduling the construction of GUI in the Event Dispatcher Thread (EDT) it quits.
- So its EDT's responsibility to handle the GUI.
Now coming to your code:
- Initial Thread is the main() thread, and EDT is the GUI Thread.
- In EX1 you are forcing the GUI to run on the main() thread which is a wrong way to do it, where as in EX2 when you use the GridBagLayoutTester which extends JPanel, main() thread gets an early chance to quite by delegating the work of GUI to the EDT.
- main() method should be used on to execute the EventQueue.invokeLater() method which further deals with the GUI, this will help the UI to be responsive and avoid dealing with any Non-UI work.
- Moreover Java has SwingUtilities Class that does a great synchronization between the UI and Non-UI work on the UI and Non-UI thread respectively.
Eg: The proper way of doing it.......
public class Test extends JFrame{
public Test(){
this.setSize(300,300);
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
public static void main(String[] args){
EventQueue.invokeLater(new Runnable(){
public void run(){
new Test().setVisible(true);
}
});
}
}

Your very first line in the main method creates a new object of type JFrame. This creation starts a new thread (in reality it starts more than one thread) - a new thread that waits for event queue items. This can be a mouse click for example.
To answer your question: The main thread - which is really called "main" - is invoking your 10 lines of code of the main method. This should be finished in some milliseconds. After that the main thread is gone, not existend anymore.
But as I said before, the AWT/Swing library has internally created one (yes, more) thread that is basically an ininite loop checking for user input. And the actionPerformed method is invoked from this thread.
My suggestion for you:
Create a breakpoint in your first line of the main method.
Debug your program.
When the debugger stops at line one (before JFrame is created) go to your command line and start jconsole
go to tab threads
notice thread "main"
execute single line (new JFrame)
notice coexistence of thread "main" and thread(s) "AWT-*"
press play on debugger and "main" will be gone but AWTs will persist

Related

Multithreading extended panel

I'm trying to allocate a JPanel that implements Runnable interface in a JFrame. I'd made this sample for interpret my idea. I want to add a multi-threading panel that shows a text as demo to a window with a String as parameter of a new instance. The panel should have independent process so I implemented Runnable interface. But when I try to create a new instance o panel with a new instance of my class, It doesn't work.
What I am doing wrong?
imagePanel Panel class:
public class imagePanel extends JPanel implements Runnable{
JLabel imageTest;
public imagePanel(String textLabel)
{
this.setPreferredSize(new Dimension(300,300));
imageTest = new JLabel(textLabel);
imageTest.setPreferredSize(this.getPreferredSize());
}
public void setImageText(String newText){
imageTest.setText(newText);
}
public void run(){
this.add(imageTest);
}
}
Main class test class:
public class test {
public static void main(){
JFrame frame = new JFrame("Test Window");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setPreferredSize(new Dimension(300,300));
JPanel panel = new imagePanel("Text label");
panel.setPreferredSize(frame.getPreferredSize());
frame.add(panel);
frame.setVisible(true);
}
}
Swing is not thread safe, meaning updates to the UI should only be made from within the context of the Event Dispatching Thread. See Concurrency in Swing for more details and Worker Threads and SwingWorker for a possible solution
Swing layouts are lazy, which is a good thing, they won't update till you tell them (or some other event requires them to update, for example, the container is resized). You can trigger an update by calling revalidate and repaint on the container you are updating
Creating a new instance of class doesn't magically connect all the instances you might have, that would make the program rather difficult to manage
there several things missing
VERY IMPORTANT - you should not update UI in other than the AWT EventDispatcher threads. Using Swing it even may lead to deadlocks. this post
you have to use the SwingUtilities to update the Swing UI components.
SwingUtilities.invokeLater(new Runnable(){
public void run(){
// update your UI components
}
});
Next information - How you create a multi-threaded thread? What you miss is the entry point to run your "run" method:
public class MyMultiThreadedType implements Runnable {
public void run() {
// this will run in parallel
}
public static void main(String[] args) {
MyMultiThreadedType mmt = new MyMultiThreadedType ();
Thread t = new Thread(mmt);
t.start(); // this will start a parallel thread
}
}

How to make Jlabel visible and invisible using for loop in java? [duplicate]

Hello guys I am doing a thread to update a ball over JFrame so I repaint the screen... and then paint the ball update its position .. and then draw the screen again ... draw the ball and the same cycle ... here is the code
private void jButton3ActionPerformed(java.awt.event.ActionEvent evt) {
Thread t = new Thread()
{
public void run()
{
while(true)
{
repaint();
b2.update(ob,2);
b2.paint(ob.getGraphics());
b2.setT(b2.getT() + 1);
try {
Thread.sleep(50);
} catch (InterruptedException ex) {
System.out.println("Error in Sleeping");
}
}
}
};
t.start();
}
but the problem is that I don't see the ball... the paint of the screen always overrides the ball and the ball is like down under the Jframe ..
If you want to have animations in Swing, the recommended class to use is the javax.swing.Timer . This class allows you to perform operations on the Event Dispatch Thread at regular intervals.
The Swing Timer tutorial
An animation example posted here on SO (which is linked in the Swing wiki here on SO btw)
Some General Rules
Swing is not thread safe, you should only ever update UI components from within the context of the Event Dispatching Thread.
You do not control the paint process, the repaint manager does. You can request updates to occur by calling repaint, but you should never call update and paint directly when trying to update the display.
The Graphics context used by the paint sub system is a shared resource and is not guaranteed to be the same between paint cycles, you should never maintain a reference to it. You should also not rely on the results from JComponent#getGraphics this method is capable of returning null.
An Example Solution
You have a number of options, depending on what you want to ultimately achieve.
You could use a SwingWorker, but given the fact that all your going to is enter an infinite loop and it would easier to use SwingUtilities#invokeLater then actually use the publish method, this approach would actually be more work.
You could also use a Thread, but you'd end up with the same problems as using a SwingWorker
The simpliset solution, for what you're presented, is actually a javax.swing.Timer
public class Blinky {
public static void main(String[] args) {
new Blinky();
}
public Blinky() {
EventQueue.invokeLater(new Runnable() {
#Override
public void run() {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (ClassNotFoundException | InstantiationException | IllegalAccessException | UnsupportedLookAndFeelException ex) {
}
JFrame frame = new JFrame("Test");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setLayout(new BorderLayout());
frame.add(new BlinkyPane());
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
});
}
protected class BlinkyPane extends JPanel {
private JLabel blinkyLabel;
private boolean blink = false;
public BlinkyPane() {
setLayout(new GridBagLayout());
blinkyLabel = new JLabel("I'm blinking here");
blinkyLabel.setBackground(Color.RED);
add(blinkyLabel);
Timer timer = new Timer(250, new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
blink = !blink;
if (blink) {
blinkyLabel.setForeground(Color.YELLOW);
} else {
blinkyLabel.setForeground(Color.BLACK);
}
blinkyLabel.setOpaque(blink);
repaint();
}
});
timer.setRepeats(true);
timer.setCoalesce(true);
timer.start();
}
#Override
public Dimension getPreferredSize() {
return new Dimension(200, 100);
}
}
}
You can take a look at Swing Timer and Concurrency in Swing for more info
If you access GUI components outside the EDT (Event Dispatch Thread) then you might encounter strange problems, Contrary if you perform long running tasks in the EDT then also you will get problems.
Check this post for more info on GUI Threading in Java

Java Swing Program- Input from GUI to Main getting stuck

I have a Java program where I plan to take input from GUI, and use that input later for processing in main(). I am using Eclipse.
I am sending an HW object(called HWObj) to the GUI JFrame, and checking for a boolean field in the object to continue processing in main().
InputWindow is custom object which extends JPanel implements ActionListener
It contains a reference to the current JFrame(parentFrame). On clicking a JButton in InputWindow, I have written a custom ActionListener which sets the value of HWObj.check to true and disposes the parentFrame. This should cause execution to resume in main().
Code for HW class is as below :
import java.awt.*;
import javax.swing.*;
public class HW {
//globals
boolean check;
public HW() {
//initialisations
check = false;
}
public static void main(String args[]) {
final HW problem = new HW();
try {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
//Create and set up the window.
JFrame frame = new JFrame("Select folders");
frame.setPreferredSize(new Dimension(640, 480));
frame.setResizable(false);
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
InputWindow Directories = new InputWindow(problem, frame);
Directories.setOpaque(true);
frame.add(Directories);
//Display the window.
frame.pack();
frame.setVisible(true);
}
});
} catch(Exception e) {
System.out.println("Exception:"+e.getLocalizedMessage());
}
while(!problem.finish);
//Do processing on problem
System.out.println("Done");
}
}
The Actionlistener in the gui is as follows:
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class InputWindow extends JPanel
implements ActionListener {
private static final long serialVersionUID = 4228345704162790878L;
HW problem;
JFrame parentFrame;
//more globals
public InputWindow(HW problem, JFrame parentFrame) {
super();
this.setLayout(new GridBagLayout());
GridBagConstraints gbc = new GridBagConstraints();
this.parentFrame = parentFrame;
this.problem = problem;
JButton finishButton = new JButton("Finish");
finishButton.setActionCommand("fin");
finishButton.addActionListener(this);
gbc.gridx = 0;
gbc.gridy = 0;
this.add(finishButton, gbc);
//Initialize buttons and text areas and labels
//Code removed for ease of reading
}
public void actionPerformed(ActionEvent e) {
String command = e.getActionCommand();
if(command.equals("fin")) {
//Do a lot of stuff, then
this.removeAll();
parentFrame.dispose();
problem.check = true;
}
}
}
I have checked, and the control to this function comes normally on button click.
Now, I would expect it to return to main, and exit the while loop, and continue processing.
This does not happen. The debugger in eclipse shows only the main thread running, and when I try to pause it, I see that the thread is stuck in the while loop. But if I try to step through, it exits the while loop as expected, and continues. However, it gets remains stuck in the while loop until I manually try to debug it.
What is the problem? Why is it not resuming the main thread as expected?
How do I resolve this issue?
Your problem is to do with how the Java memory model works. The loop in your main thread will be checking a stale value of check.
When you enter the debugger, the memory is forced to be updated, so that's why it starts working at that point.
If you mark your variable as volatile, that will force the JVM to ensure that all threads are using the up-to-date value:
volatile boolean check;
You can read more about volatile and the Java memory model in the documentation.
It looks like you're using a JFrame where you should be using a modal JDialog. If you use the modal JDialog for an input window, you will know exactly when it is "finished" since code flow will resume from the calling code from right after when the dialog was set visible.
Either that or if you are trying to swapviews, then use a CardLayout to swap your view, and use an observer type pattern to listen for change of state.

java thread problem

I wrote a simple program with java swing which suppose to start another thread and in that thread a JForm will show up when I click a button. But JForm is not showing up... I used if (Thread.currentThread().getName() == "Thread1") to do the specific task for that thread, when I comment that program runs perfectly, I can't understand why it is not going to the if block... Please someone help me with this...
Thanks in advance!
Here is the code,
public class Test extends JFrame implements ActionListener {
JPanel panel;
JButton button;
public Test() {
setVisible(true);
setSize(300, 300);
setDefaultCloseOperation(DISPOSE_ON_CLOSE);
panel = new JPanel();
button = new JButton("click me");
button.addActionListener(this);
panel.add(button);
add(panel, BorderLayout.CENTER);
}
public static void main(String[] args) {
Test tst=new Test();
}
#Override
public void actionPerformed(ActionEvent arg0) {
if(arg0.getSource()==button){
System.out.println("test");
test2 test = new test2();
Thread tr1 = new Thread(test);
tr1.setName("Thread1");
tr1.start();
}
}
}
class test2 implements Runnable{
public void run() {
//if (Thread.currentThread().getName() == "Thread1") {
System.out.println("inside thread");
JFrame frame2=new JFrame();
frame2.setVisible(true);
frame2.setSize(300, 300);
frame2.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
//}
}
}
Try using getName().equals("Thread1") instead.
equals compares the strings, == checks if the two strings are the same object.
Try:
if (Thread.currentThread().getName().equals("Thread1"))
or
if (Thread.currentThread().getName().compareTo("Thread1") > 0)
why do you have that check for the current threads name anyway? That thread will be the only one to call that method anyway.
You must not compare String values using == as it checks for object identity. You should use Thread.currentThread().getName().equals("Thread1") instead.
You should not interact with any Swing/AWT components outside of the Event Dispatch Thread!

(Java) Appearing/Disappearing JLabel in a JPanel only disappears on resize

I'm working in Java, and I have a JPanel in a JFrame. In that JPanel, among other things, I have a JLabel that I want to make appear and disappear at will. I've tried setting visibility to true/false, adding and removing it from the JFrame and JPanel, and, having looked online, I tried validate()ing and revalidate()ing ad infinitum. What can be done here to solve this problem?
In general, calling the setVisible method is sufficient to make a Swing component to be shown or hidden.
Just to be sure that it works, I tried the following:
public class Visibility {
private void makeGUI() {
JFrame f = new JFrame();
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
final JLabel l = new JLabel("Hello");
final JButton b = new JButton("Hide Label");
b.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
l.setVisible(false);
}
});
f.getContentPane().setLayout(new BorderLayout());
f.getContentPane().add(l, BorderLayout.CENTER);
f.getContentPane().add(b, BorderLayout.SOUTH);
f.setSize(200, 200);
f.setLocation(200, 200);
f.validate();
f.setVisible(true);
}
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new Visibility().makeGUI();
}
});
}
}
The above program is able to affect the visibility by clicking on a JButton.
Could it be a Threading Issue?
My next suspicion was that perhaps a Thread that is not on the event dispatch thread (EDT) may not be affecting the display immediately, so I added the following after initializing the JLabel and JButton.
Thread t = new Thread(new Runnable() {
public void run() {
while (true) {
b.setVisible(!b.isVisible());
try {
Thread.sleep(100);
} catch (InterruptedException e) { /* Handle exception /* }
}
}
});
t.start();
With the new Thread running, it changed the toggled the visibility of the JLabel every 100 ms, and this also worked without a problem.
Calling a Swing component off the event dispatch thread (EDT) is a bad thing, as Swing is not thread-safe. I was a little surprised it worked, and the fact that it works may just be a fluke.
Repaint the JPanel?
If the JLabel's visibility is only being affected on resizing, it probably means that the JLabel is being drawn only when the JPanel is being repainted.
One thing to try is to call the JPanel's repaint method to see if the visibility of the JLabel will change.
But this method seems to be just a band-aid to a situation, if the main cause is due to a thread off the EDT is attempting to make changes to the GUI. (Just as a note, the repaint method is thread-safe, so it can be called by off-EDT threads, but relying on repaint is a workaround than a solution.)
Try using SwingUtilities.invokeLater
Finally, probably the thing I would try is the SwingUtilities.invokeLater method, which can be called (and should only be called) from a thread running separate from the EDT, if it wants to affect the GUI.
So, the earlier Thread example should be written as:
Thread t = new Thread(new Runnable() {
public void run() {
while (true) {
try {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
b.setVisible(!b.isVisible());
}
});
} catch (Exception e1) { /* Handle exception */ }
try {
Thread.sleep(100);
} catch (InterruptedException e) { /* Handle exception */ }
}
}
});
t.start();
If the change to the GUI is indeed occurring on a separate thread, then I would recommend reading Lesson: Concurrency in Swing from The Java Tutorials in order to find out more information on how to write well-behaving multi-threaded code using Swing.
setVisible() or removing it should work fine, make sure you are doing it from the event dispatch thread though. There are utility methods in EventQueue for running blocks in that thread.
http://helpdesk.objects.com.au/java/how-do-i-update-my-gui-from-any-thread
You would need to call revalidate() on the parent JPanel if you need its components to be re-laid out.
If you can post an example that demonstrates the problem I can have a look at it for you.

Categories