GUI Updation Problem with JTextPane

[Sameer]

A simple chatting system i am dealing with is as follows:
The Client accepts text in a TextField and sends it to a server.
Server sends it to all the connected clients.
The message received by Client is appended to a JTextPane.
This works fine

I have written one special client in which using the 'Robot' class of
AWT, It automatically enters the text 'TESTING' in the TextField and
let it press the Enter key. The Testing method is set to run in an
indefinite loop so that this Client will send this message continuosly
after some delay.

This mechanism also works....
but the problem is that when this is happening on the screen, the other
components of the system like JList, contents of JTextPane are not
displayed. It just shows the text being typed in the TextField but the
rest GUI is not updatable.

I tried using

jtextpane.updateUI();
jtextpane.validate();
SwingUtilities.updateComponentTreeUI(Component c)

but it wont work.

What may be the problem?
Please help.
-Sameer

 

[Andrew Thompson]

On 15 Aug 2005 03:29:39 -0700, Sameer wrote:
....

Server sends it to all the connected clients.

Speaking of which. Please cross-post, in future.
<http://www.physci.org/codes/javafaq.jsp#xpost>

 

[jan V]

This mechanism also works....

but the problem is that when this is happening on the screen, the other
components of the system like JList, contents of JTextPane are not
displayed. It just shows the text being typed in the TextField but the
rest GUI is not updatable.

Sounds like you're breaking the (well known?) rule to always perform GUI
component updates on the AWT/Swing event thread. Breaking this rule often -
though not always - results in dysfunctional, frozen GUIs...

 

[Roedy Green]

This mechanism also works....
but the problem is that when this is happening on the screen, the other
components of the system like JList, contents of JTextPane are not
displayed. It just shows the text being typed in the TextField but the
rest GUI is not updatable.

Here is some general advice that may be relevant.

Swing is single thread. If you do anything non-trivial in a Listener
you will hold up the entire GUI. It can't do ANYTHING until you are
done.

So you should spawn a separate thread to do anything non-trivial. If
your thread needs to update the GUI, it can't touch Swing components
directly. Only the Swing thread can run Swing methods. You must use
the indirect approach with SwingUtilities.invokeLater( Runnable ) or
SwingUtilities.invokeAndWait( Runnable ) which enques a work packet
for the Swing thread. see http://mindprod.com/jgloss/swing.html
http://mindprod.com/jgloss/thread.html


If you already know this, please don't feel offended; consider that
there are others reading who do not know this who will some day run
into similar problems to the ones you are having.

 

[Sameer]

Thanks! Now I understand the importance of cross-posting. I will
remember it in future.

How to follow the rule-
"To always perform GUI
component updates on the AWT/Swing event thread"

I tried by invoking the testing-loop in a separate thread using

SwingUtilities.invokeLater( Runnable ) and
SwingUtilities.invokeAndWait( Runnable )

but still it can't solve my problem- the GUI of JTextPane do not show
its contents.

Please help.
-Sameer

 

[Andrew Thompson]

How to follow the rule-
"To always perform GUI
component updates on the AWT/Swing event thread"

I tried by invoking the testing-loop in a separate thread using

SwingUtilities.invokeLater( Runnable ) and
SwingUtilities.invokeAndWait( Runnable )

This tells me (almost) nothing. [1]

but still it can't solve my problem- the GUI of JTextPane do not show
its contents.

[1] I could ask the '101 questions' that would explain
the exact cirumstances from which you are calling the
methods, or you might pen/type 70-80 lines of SSCCE[2]
that explain far better.

I suggest the SSCCE.

[2] <http://www.physci.org/codes/sscce.jsp>

 

[Roedy Green]

but still it can't solve my problem- the GUI of JTextPane do not show
its contents.

One of your Listeners is doing something, sleeping perhaps, waiting
for another thread? that is holding up the works. Listeners have to
complete very quickly since they are holding up the Swing thread that
has to do all the GUI work.

Brute force technique is to put some debug output at the beginning and
end of each listener code that times how long it took.

 

[Sameer]

The 'SwingWorker' class available on the net (just search for it) is
quite helpful in this situation.

This is just for completion of this thread and information for others
catched in such situation.

 

[Roedy Green]

The 'SwingWorker' class available on the net (just search for it) is
quite helpful in this situation.

for a link to the download and docs, see
http://mindprod.com/jgloss/thread.html