Swing thread conflict?

I have a JSlider that is used to adjust the saturation of the current color
used by a LookAndFeel that my project uses. I seem to be having a
thread conflict, but can't seem to resolve it.
I have a MouseEvent listener attached to the JSlider:
class ClickListener extends MouseAdapter
      //AdvColorChooser parent;
      public ClickListener(AdvColorChooser theParent)
          //parent = theParent;
      public void mouseReleased(MouseEvent me)
       /// get slider value and pass it to the LookAndFeel, which
       /// does some UI stuff which is pure magic to me
       /// (the computations may or may not be expensive)
      /// now all i need to do is update the component tree,
      /// which is where I have the problem:
       new SwingWorker()
          public Object construct()
                SwingUtilities.updateComponentTreeUI(currentWindow);
                return null;
        }.start();
                inited = true;
}I have tried to update the component thread both inside of a SwingWorker and also just by making the call by itself. I have experimented with wrapping different parts of code in the SwingWorker, but still get the same errors:
java.lang.NullPointerException
        at javax.swing.plaf.basic.BasicSliderUI$TrackListener.mouseReleased(BasicSliderUI.java:1343)
        at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:232)
        at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
        at java.awt.Component.processMouseEvent(Component.java:5488)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
        at java.awt.Component.processEvent(Component.java:5253)
        at java.awt.Container.processEvent(Container.java:1966)
        at java.awt.Component.dispatchEventImpl(Component.java:3955)
        at java.awt.Container.dispatchEventImpl(Container.java:2024)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
        at java.awt.Container.dispatchEventImpl(Container.java:2010)
        at java.awt.Window.dispatchEventImpl(Window.java:1774)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:153)
        at java.awt.Dialog$1.run(Dialog.java:517)
        at java.awt.Dialog$2.run(Dialog.java:545)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.awt.Dialog.show(Dialog.java:543)
        at java.awt.Component.show(Component.java:1300)
        at java.awt.Component.setVisible(Component.java:1253)
        at AdvColorChooser.showGUI(AdvColorChooser.java:1769)
        at AdvColorChooser.<init>(AdvColorChooser.java:98)
        at ColorChooser.actionPerformed(ColorChooser.java:883)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234)
        at org.jvnet.substance.utils.RolloverButtonListener.mouseReleased(RolloverButtonListener.java:110)
        at java.awt.Component.processMouseEvent(Component.java:5488)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
        at java.awt.Component.processEvent(Component.java:5253)
        at java.awt.Container.processEvent(Container.java:1966)
        at java.awt.Component.dispatchEventImpl(Component.java:3955)
        at java.awt.Container.dispatchEventImpl(Container.java:2024)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
        at java.awt.Container.dispatchEventImpl(Container.java:2010)
        at java.awt.Window.dispatchEventImpl(Window.java:1774)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:153)
        at java.awt.Dialog$1.run(Dialog.java:517)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)By the way, I chose to use a MouseEvent rather than a ChangeListener
because the computations are expensive, and I don't want to call the
methods until the slider bar has stopped.
I suppose it's possible the fault is with the LookAndFeel's author, but I
find it much more likely that I'm doing something wrong.
Any ideas would be greatly appreciated. Thanks.

Instead of using a SwingWorker, try wrapping your code in a SwingUtilities.invokeLater(...). This adds the code to the end of the GUI event Thread, so it should execute after the slider has finished updating itself.

Similar Messages

Killing a Swing thread

Hello,
How can I kill a Swing thread? For example the program below would never exit. Sure you can type System.exit(0) which would exit anything, but what are the other solutions?
I tried putting chooser = null;
System.gc();in the end of main() but this won’t work.
To formulate my question better - how would I kill a thread I do not have complete command of (i.e. I can’t do usual do/while thread stopping)?
Big thanks in advance.
public class SwingLiveTest{
    public static void main(String[] args) {
        JFileChooser chooser = new JFileChooser();
        if (chooser.showSaveDialog(null) != JFileChooser.APPROVE_OPTION) return;
        File file = chooser.getSelectedFile();
        System.out.println(file);
        /*chooser = null;
        System.gc(); */

You can't kill any Thread like this, at least not those where there is no method to call.
It is possible to cause a Thread to stop, call the stop method, however this is not the recommended approach for very good reasons (Read the JavaDocs for java.lang.Thread.stop() method to see why.
It should be possible, once you have obtained a reference to the Thread you wish to stop, to call interrupt() on that Thread.
This is not guaranteed to work because you are dependent on the implementation of the Thread class you are manipulating or the Runnable that the Thread instance is currently running.
There may be classes in the com.sun packages which can aid you with this problem, this is where Sun usually sticks undocumented implementation however these packages are not officially supported and there is no guarantee that classes you use in one VM are available in another, in particular when the VM you are using is not a Sun VM.

In this case, can I modify swing GUI out of swing thread?

I know the Swing single thread rule and design (Swing is not thread safe).
For time-consuming task, we are using other thread to do the task and
we use SwingUtilities.invokeAndWait() or SwingUtilities.invokeLater (or SwingWorker) to update Swing GUI.
My problem is, my time-consuming task is related to Swing GUI stuff
(like set expanded state of a huge tree, walk through entire tree... etc), not the classic DB task.
So my time-consuming Swing task must executed on Swing thread, but it will block the GUI responsivity.
I solve this problem by show up a modal waiting dialog to ask user to wait and
also allow user to cancel the task.
Then I create an other thread (no event-dispatch thread) to do my Swing time-consuming tasks.
Since the modal dialog (do nothing just allow user to cancel) is a thread spawn by
Swing event-dispatch thread and block the Swing dispatch-thread until dialog close.
So my thread can modify Swing GUI stuff safely since there are no any concurrent access problem.
In this case, I broke the Swing's suggestion, modify Swing stuff out of Swing event-dispatch thread.
But as I said, there are no concurrent access, so I am safe.
Am I right? Are you agree? Do you have other better idea?
Thanks for your help.

If you drag your modal dialog around in front of the background UI, then there is concurrent access: paint requests in your main window as the foreground window moves around.

Swing & Threads....help me!

Hi all,
I am writting an application that requires a file to be read. I need to be able to read a file and display the first 10 lines of the file into a Jeditorpane, and display it , while still processing the rest of the file to also display it in an other jeditorpane.
Or is it possible to read the first 10 lines, display them... and continue to read the rest of the file and finaly overwrite the existing jeditorpane.??
I was thinking of using threads to do this task.
Any comments are welcome.

WRITING LIKE THIS!!!!!! DOES NOT!!!!!! MAKE PEOPLE!!!! WANT TO ANSWER YOUR!!!!! QUESTIONS!!!!!! IN FACT,!!!!!! IT'S RATHER ANNOYING!!!!! TO READ!!!!!! AND VERY!!!! FEW PEOPLE WILL!!!!!! BOTHER TO READ A POST!!!!!! THAT LOOKS LIKE!!!!! THIS!!!!!!!
To repeat the excellent guidelines from JavaRanch:
* We all answer questions here voluntarily, in our leisure time. We do that because doing so is fun for us, because we enjoy helping people and having interesting discussions. Guess what? It is much less fun if it gets stressful. So the last thing you want to do to get us to answer your question is to pass your stress over to us.
* People who are stressed and want a fast answer often don't even find the time to do the necessary research or to formulate their question in an easy to comprehend way. That's even less fun to work with. So you really don't want us to feel your stress. Instead you want to take your time to write a well formulated post that is fun to answer. The less likely it is for us to know that your question is urgent, the more likely you are to get a fast answer!
* The simple notion that you want your post to be answered faster than those of the other members might feel rather unfair to some of us. Doubly so because often "urgent" questions actually are homework questions. Yours might be different, but someone who had bad experiences with this type of question might not read far enough to notice.
* If it is really that urgent, my answer may already come too late, so I will think twice before taking the time to formulate it.
* Last but not least, having the word "urgent" in the subject line actually obfuscates it, makes it harder to decipher what the actual question is, and therefore to decide to actually read the thread. This grossly conflicts with the important practice to UseAMeaningfulSubjectLine.
~

Swing/Threads, changing the GUI

Hey all, I have a question related to the java swing class, and manipulating a GUI which is something that I have never done before. Basically I have a threaded Listener class which returns a status boolean. Related to that status, I have a Jlabel which is supposed to display green if the status is true, and red if the status is false, however it is not working correctly. Below is my code, and I would appreciate some help if anyone has a fix, or better way to do this... Thanks in advance
//Listener Class
public class Listener extends Thread{
     private boolean isGood = false;
     public Listener(//...) {
     public void run()
          // does stuff here that sets the isGood var
     public bool getIsGood()
          return this.isGood;
//GUI
public class Visualizer {
     private static Listener listener;
     public Visualizer(Listener listener){
          this.listener = listener;
          javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
     private static JFrame frame;
     private static JLabel status;
     public static void createAndShowGUI() {
//Create and set up the window.
frame = new JFrame("Window");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
status = new JLabel("Listener... ");
status.setOpaque(true);
status.setBackground(Color.RED);
//Display the window.
frame.pack();
frame.setVisible(true);
frame.setSize(new Dimension(204, 115));
frame.setContentPane(status);
listener.start();
while(true){
     boolean isGood = listener.getIsGood();
if(isGood){
status.setBackground(Color.GREEN);
else{
status.setBackground(Color.RED);
     try{
          Thread.sleep(1000);
     }catch(Exception E){
          E.printStackTrace();
I purposely left out some of the code because I wanted to make it simpler to follow. Essentially this is what is going on, and hopefully someone can point out why its not working and how to fix it. Thank you for reading this.

thanks for the advice Petes, I was looking for the code tag before but didnt see it. I have created an SSCCE, and I apologize for not making it earlier. Here is the code. The threads seem to be getting stuck, and the label doesnt alternate between red and green as it should. Let me know if you need anything else:
package simplified;
public class Main{
     public static void main(String[] args) {
          Listener theListener = new Listener();
          theListener.start();
          Visualizer theView = new Visualizer(theListener);
//Listener Class
public class Listener extends Thread{
     private boolean isGood = false;
     public Listener() {
     public void run(){
          if(this.isGood == true){
               this.isGood = false;
          else{
               this.isGood = true;
          try{
               this.sleep(1000);
          }catch(Exception e){
               e.printStackTrace();
     public boolean getIsGood(){
          return this.isGood;
import java.awt.*;
import javax.swing.*;
import java.awt.Dimension;
public class Visualizer {
     private static Listener listener;
     public Visualizer(Listener listener){
     this.listener = listener;
     javax.swing.SwingUtilities.invokeLater(new Runnable() {
          public void run() {
               createAndShowGUI();
     private static JFrame frame;
     private static JLabel status;
     public static void createAndShowGUI() {
          //Create and set up the window.
          frame = new JFrame("Window");
          frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
          status = new JLabel("Listener... ");
          status.setOpaque(true);
          status.setBackground(Color.RED);
          //Display the window.
          frame.pack();
          frame.setVisible(true);
          frame.setSize(new Dimension(204, 115));
          frame.setContentPane(status);
          while(true){
               boolean isGood = listener.getIsGood();
               if(isGood){
                    status.setBackground(Color.GREEN);
               else{
                    status.setBackground(Color.RED);
               try{
                    Thread.sleep(1000);
               }catch(Exception E){
                    E.printStackTrace();
}

Swing Threads

Does anybody know how the threads in a swing application are organized. I noticed, that when i start a swing application more then 10 threads are created. Furthermore, when the "main" thread is terminated after showing the main window (a JFrame window), two windows are displayed. When the main-thread is ran in a loop (while (true) {try{Thread.sleep(100);}catch(Exception x){}), only one window is displayed. So, even if the main thread does nothing, it's necessary.
Furthermore, i realized that, when starting other threads out from the main thread, on some win 2000 systems the threads are properly terminated but the associated handles are not freed - this leads to a "handle leak" after a certain time (48 hours). If the threads are started with invokeLater out from the main thread, then the handles are freed properly when the thread terminates.
Does anybody know how these facts can be put together to get a bigger whole ?
Thanks a lot.
Stephan Gloor
Switzerland

hi,
the rule is:
swing components are not thread-safe except some, and therefore they should only be changed from within the event dispatch thread. this can be accomplished using the methods invokeLater(Runnable) and invokeAndWait(Runnable) in class javax.swing.SwingUtilities.
best regards, Michael

How does deadlocking happen when not updating UI on swing thread?

It looks like the 2 objects that cause the deadlock are the RepaintManager and the JComponent.LOCK object...but I can't really find a scenario where this happens in the code.
Can anybody shed some light on this?

Basic rule of thumb:
If you can't guarantee that your code will run on the AWT-Event thread then wrap your calls in a SwingUtilities.invokeLater() call (or its cousin invokeAndWait()).
Basically this looks like:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
// put your gui updating code here
There are two ways to make something thread safe:
1) Guarantee calls will always come from the same thread
2) Synchronized shared objects.
Swing chose choice 1 since choice 2 would be two big of a performance hit. The thread it uses is the AWT-Event thread. The invokeLater call tosses your Runnable object at the end of the Event Queue. The AWT-Event thread pops a Runnable off the Event Queue processes it and then repeats.
As to specifically whats happening, I can't say without more information. Really you should go back and make sure all your Swing calls are on the AWT-Event thread. That should solve your current problem and prevent future problems.

Swing Thread handling

Dear all,
The question is as the follow:
Condition
Class A purpose: Get Data from SQL server 2000 e.g.
SQLDB transaction = new SQLDB();
transaction.getData();
Now, I would like to handle the transaction time in order to show that it is processing with Swing component: JLabel, JButton and JFrame. How to write a swing program? Please help me or give me some reference. Thank you so much for your help!
Regards,
kzyo

If java 6, this is an article which I think will probably help you immensely:
http://java.sun.com/developer/technicalArticles/javase/swingworker/
It's all about how to implement SwingWorker, a background threader that can among other things give progress reports to the GUI.
Message was edited by:
petes1234

That old chestnut: Swing Threading - EventQueue

First of all, I'm sorry if this topic has been done to death already but I really have searched through the forums and tutorials and not found a solution that I can get to work.
Scenario (the usual):
- Swing GUI application
- Button fires off 'IntensiveProcess'
- Display a 'MessageBox' while 'IntensiveProcess' is running
Problem:
MessageBox is not displayed (or is displayed but its contents are not painted - depending on which [incorrect] implementation I try) until IntensiveProcess has finished.
I have tried all kinds of different ways of accomplishing this but I can't for the life of me get it to work:
The implementations I have tried involved various combinations of:
- EventQueue.invokeLater()
- EventQueue.invokeAndWait()
- inner and annonymous-inner Runnable classes
As far as I understand it, the following strategy should work:
public class MySwingApp extends JFrame
    //create button with Action: DoButtonAction
    private class DoButtonAction extends AbstractAction
        public void actionPerformed(ActionEvent e)
            // ~~~ IMPLEMENTAION 1 ~~~
            EventQueue.invokeLater(new ShowMessageBox());
            EventQueue.invokeLater(new IntensiveProcess());
            // ~~~ IMPLEMENTAION 2 ~~~
            EventQueue.invokeLater(new ShowMessageBox());
            //cannot call invokeAndWait() from Event Dispatcher thread so:
            (new Thread(new Runnable()
                public void run()
                    EventQueue.invokeAndWait(new IntensiveProcess());
            )).start();
            // ~~~ IMPLEMENTAION 3 ~~~
            EventQueue.invokeLater(new IntensiveProcess());
            //cannot call invokeAndWait() from Event Dispatcher thread so:
            (new Thread(new Runnable()
                public void run()
                    EventQueue.invokeAndWait(new ShowMessageBox());
            )).start();
            //dispose of message box if user didn't close it
    private class ShowMessageBox implements Runnable
        //display MessageBox...
    private class IntensiveProcess implements Runnable
        //execute intensive process...
}None of the above 3 implementations yield the correct result.
Can anyone please point out where I'm going wrong?
Thanks all.
John

I have implemented your suggestion but sadly I am
getting the same result: the entire GUI hangs until
IntensiveProcess has completed, and only then is the
message box displayed.Hmm, with the intenstive process in its own thread (construct() runs in a thread other than EDT) the GUI shouldn't hang like that, I'm not sure why that is. Maybe try invokeAndWait instead. Or, did you try displaying the message box before creating the SwingWorker? Make sure the message box is not modal if you create it before creating SwingWorker.
I can't grasp why the EventDispatcher thread is
getting tied up with IntensiveProcess. I thought
calling EventQueue.invokeLater() (or SwingWorker) is
supposed allow the executing thread (in my case the
EventDispatcher thread) to continue. So why is the
GUI not getting updated and the message box being
displayed until AFTER IntensiveProcess finishes?As I understand it, invokeLater means stuff this Runnable into the event queue and run it when its turn comes up, while invokeAndWait runs the Runnable immediately. Neither method will wait for another thread to finish like you're expecting, that's what SwingWorker does.
For some background info, the SwingWorker's construct() method creates a new non-EDT thread, which is where you're supposed to do time-intensive background work, and the code inside the finished() method will be run in the EDT, which is where you're supposed to update Swing components. The major benefit is the happens-before guarantee, construct() will run to completion before finished() is invoked. Maybe you already knew that, but it's important to know so I wanted to make sure.

Swing thread race

Hi,
I have a problem with the JTree. I have implemented a model for a sort of filesystem, viewable by a JTree. When I click to expand the tree, it seems like the AWT thread block while waiting for the tree node to report its children. Inside the node implementation, I get an error that causes the invokation of a JOptionPane, which in turn causes the gui to crash. I suppose it's because the application tries to show a dialog while the gui thread is busy?
How can I work this out...?
BR,
Michael

The Swing tutorial on [url http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html]Using Threads explains the concept of "Thread Safe".

Swing thread safe ?

Hi
Are swing comonents are thread safe ?
If i am not wrong the thread safe objects are those whose data changes are predictable ( i mean no race condition)
Is this correct ?
I had worked on multithreaded application in MFC where we used Message queues for hadling the multithreading
Can i use the same logic in java also ? If yes can anybody help me how can i do it
Thanks in advance

The Swing tutorial on [url http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html]Using Threads explains the concept of "Thread Safe".

Swing thread performance in linux

Hello,
I am writting very small swing application for learning students...
There is Robot object(s) which can walk through Panel and draw lines...
But I have there some performance problems with threads in linux...
In Windows is everything ok... but not in linux...
code is very short... every Robot object has reference to PaintPanel
extends JPanel. When robot do forward method, it paints DrawableLine.
Painting is following through PaintPanel.drawShape(final Drawable shape)
In MainFrame is little example method runRobots() which draw some
pictures. When I added this method (runRobors) to thread, it is going
very slow on linux...
sources are here:
http://homer.dactos.com/~hlavki/robot.zip
thanks, miso

camickr,
Good call. that was what it wanted. Runs like a scalded dog without any flicker at this point.
Wrapped the calls that would result in adding a ThreadMonitor, Removing a ThreadMonitor or updating a ThreadMonitor with
SwingUtilities.invokeLater(new Runnable(){
public void run(){
// do something here
}) ;and the ui is very well mannered now.
There is one gotcha for anyone who comes along after and reads this thread. This change increases the app to use more heap space and at full throttle I was able to bring the application to its knees.
Just something to be aware of.
camickr, once again thank you.
PS.

Swing thread issu

I have a javax.swing.JFrame extended object that after running the code
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new chatUi().setVisible(true);
        });Continues to communicate with a network server over TCP and updates a table with information. By calls to System.out.println I can see that the communication with the server is succesfull but I cant update the gui. The only way i seme able to update the gui after that point is by events that are triggerd by the user and not by functions in my code.
What am I missing ?
Is the only way to work with the frame object by creating threads and running them by: SwingUtilities.invokeLater. ??
Any help would be greatly appriciated // Tomas

Hi,
A little bit of more code would be nice to see where your app don't do what it should do.
In general you should post every code that interacts with the gui into the EventDispatchThread(EDT)
a common way is to use the EventQueue as you did.
If one of your methods invokes changes on the gui you should them post on the EDT too.
If you want to look timebased for a special value or some networkoperations you can use
a Timer - in your case a javax.swing.Timer and not the java.util.Timer.
for further informations look at this tutorials :
http://java.sun.com/docs/books/tutorial/uiswing/misc/timer.html
http://java.sun.com/products/jfc/tsc/articles/timer/
An other nice way to let run longer threads posting intermediate results on the gui
is to use a SwingWorker -> javax.swing.SwingWorker
try those things
Olek

Any way to repaint JTextField while Swing Thread still running?

while the AWT event-dispatch thread is running I would like to set a new value for a Text field and have the value of that field, as seen by the user, refresh to show the new value. I could use this technique, if it's possible, to make one of the fields in my window into a status field.
I know that this can be done by doing the processing in a thread other than the AWT thread, but I was hoping there is some way to get a field to redisplay its contents to the user while the AWT thread is running.

The paintImmediately() method may do what you want.
http://forum.java.sun.com/thread.jsp?forum=57&thread=234114

Confusing Event Order in Swing Thread

hi,
i've panel which contains a text field for entering number and a submit button
sometimes new (updated) value can not be sent when i click the button (the previous value of the field is sent)
in the debug mode, i see that sometimes AbstractButton.fireActionPerformed() is called (which gets the value of the field at that time and then submits) by event dispatch thread before JFormattedTextFiled.FocusLostHandler and JFormattedTextField.commitEdit() (which updates the value of the field) .
i think jbutton event should have never been called before the text field loses the focus and updates its value
any idea about the problem?
i'm using xp-sp2 and java 1.6.0_06-b02

@macrules2
thanks, i'll take notice of your advice and please notice that it was my first post both at this forum and stackoverflow (which means i may have lack of some forum principles, sorry)
@kevinaworkman
if you really want to help someone, try to be less arrogant
@BinaryDigit
thanks for your reply. since it's part of an military project, i'm not allowed to give code samples (and all modifications are in the EDT).
actually i'm interested in the cause of the problem rather than the solution
there are two cases in the EventQueuehere are the events for case 1:
MouseEvent (MOUSE_RELEASED)
MouseEvent (MOUSE_CLICKED)
InvocationEvent
InvocationEvent
InvocationEvent
CausedFocusEvent (FOCUS_LOST; opposite: JButton; source: FormattedNumberField)
CausedFocusEvent (FOCUS_GAINED; opposite: FormattedNumberField; source: JButton)
InvocationEvent
MouseEvent (MOUSE_MOVED)
MouseEvent (MOUSE_EXITED)and here are the events for case 2:
CausedFocusEvent (FOCUS_LOST; opposite: JButton; source: FormattedNumberField)
CausedFocusEvent (FOCUS_GAINED; opposite: FormattedNumberField; source: JButton)
InvocationEvent
InvocationEvent
MouseEvent (MOUSE_RELEASED)
MouseEvent (MOUSE_CLICKED)
InvocationEvent
InvocationEvent
MouseEvent (MOUSE_MOVED)
MouseEvent (MOUSE_EXITED)maybe java does not guarantee the order of the events. if it's true it would be a common problem but it's an unusual and very rare situation. even i can't reproduce this problem in other gui panels. i wonder what may cause this problem.

Swing thread conflict?

Similar Messages

Maybe you are looking for