pluess
asked on
Modify Swing Components
Sun makes the statement:
"Once a Swing component has been realized, all code that might affect
or depend on the state of that component should be executed in the
event-dispatching thread."
Following this recommandation may cause a lot of additional code,
especially when dealing with GUI events, that trigger time consuming
tasks. I use to write event-driven programs that works like a state
machine: the listener only changes states and NOTHING ELSE. A special
thread contains a state event loop does all the task. It also updates
Swing components. Is this safe enough? (I never had a problem.)
"Once a Swing component has been realized, all code that might affect
or depend on the state of that component should be executed in the
event-dispatching thread."
Following this recommandation may cause a lot of additional code,
especially when dealing with GUI events, that trigger time consuming
tasks. I use to write event-driven programs that works like a state
machine: the listener only changes states and NOTHING ELSE. A special
thread contains a state event loop does all the task. It also updates
Swing components. Is this safe enough? (I never had a problem.)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
hey you can launch threads to complete tasks but all the threads should be executed through the event dispatching threads since the swing comp are not thread safe. You can do that using invokeLater and invokeAndWait methods in SwingUtility class
>>> but all the threads should be executed through the event dispatching threads
Nonsense, that's the only way: from the ONE event dispatching thread.
When you click a button, where do you end up? in actionPerformed()
and where is that? Yes, in that thread.
;JOOP!
Nonsense, that's the only way: from the ONE event dispatching thread.
When you click a button, where do you end up? in actionPerformed()
and where is that? Yes, in that thread.
;JOOP!
go thruogh the below link,
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
hope now it make sense!
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
hope now it make sense!
>>the 'actionPerformed()' must launch threads for all consuming processes.
Those can modify Swing components
>>
Better you read some article before making such wrong statements!
Those can modify Swing components
>>
Better you read some article before making such wrong statements!
Funny, what is wrong with that?
You said: "should be executed through the event dispatching threads".
Is there another place than in 'actionPerformed()'?
You may have read more than me, but did you ever apply this?
;JOOP!
You said: "should be executed through the event dispatching threads".
Is there another place than in 'actionPerformed()'?
You may have read more than me, but did you ever apply this?
;JOOP!
your code,
public void actionPerformed( ActionEvent ae ){
Thread thread = new Thread(){
public void run(){
//task
}
}
} // more possibility for DL
mine,
public void actionPerformed( ActionEvent ae ){
SwingUtilites.invokeLater(
public void run(){
//task
}
} ;
}
Hope u understand the diff now!
public void actionPerformed( ActionEvent ae ){
Thread thread = new Thread(){
public void run(){
//task
}
}
} // more possibility for DL
mine,
public void actionPerformed( ActionEvent ae ){
SwingUtilites.invokeLater(
public void run(){
//task
}
} ;
}
Hope u understand the diff now!
Tell me.
gothrough the link!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You did not understand the thread mechanism.
The magic is in:
p.revalidate(); // Ready.
I have written professional programs with hundreds of threads that independently painted or modified
the screen.
Of course it could all be my imagination.
pluess, can you react a bit; we are doing this all for YOU!
;JOOP!
The magic is in:
p.revalidate(); // Ready.
I have written professional programs with hundreds of threads that independently painted or modified
the screen.
Of course it could all be my imagination.
pluess, can you react a bit; we are doing this all for YOU!
;JOOP!
yes u only understand the thread mechanism, me and all who created the articles are don't!
always prevention is better than cure!
always prevention is better than cure!
From 1968: Those who can, do; those who can't, teach; those who cannot teach, publish.
Not my words.
;JOOP!
Not my words.
;JOOP!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
objects you are most experienced here.
May I presume that you agree that launching new threads
(or activating other threads) is the right way?
;JOOP!
May I presume that you agree that launching new threads
(or activating other threads) is the right way?
;JOOP!
If the processing is lengthy and you don't want to freeze your gui then you need to start a new thread.
And if that thread needs to update the gui then it should use invokeLater() and invokeAndWait() to do thos updates.
And if that thread needs to update the gui then it should use invokeLater() and invokeAndWait() to do thos updates.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I never needed that. My program was running 100's of threads for weeks (large banking conversion).
I wonder why I never had to use invokeLater() etc.
It worked as a charm.
(JAVA 5 on W2003).
;JOOP!
I wonder why I never had to use invokeLater() etc.
It worked as a charm.
(JAVA 5 on W2003).
;JOOP!
>> I never needed that.
Thread-pool?
Thread-pool?
>>If the processing is lengthy and you don't want to freeze your gui then you need to start a new thread.
And if that thread needs to update the gui then it should use invokeLater() and invokeAndWait() to do thos updates.
>>
Exactly, I just posted the code for an example!
And if that thread needs to update the gui then it should use invokeLater() and invokeAndWait() to do thos updates.
>>
Exactly, I just posted the code for an example!
JPanel p;
...............
p.add(someButton); // Button created because of some event (button?)
p.revalidate(); // That's all needed.
..........................
p.remove(someButton); // Not needed anymore.
p.revalidate(); // Ready.
;JOOP!