Hey everyone,
Now I’ve been programming for nearly two years in Java, but this one little tidbit has got me stumped.
I’ve got two separate threads running. One doing painting in a JFrame, and the other performing I/O work.
For some odd reason, when the I/O thread is doing its thing, the components refuse to paint in the JFrame. Even if I try calling repaint(), it will ignore the call until the I/O has finished.
Any ideas?
Need more info. What is the I/O thread doing exactly? Is it interacting with any of the UI stuff at all?
It’d help if you can post a stack trace when the IO/not painting happens (Ctrl+Break on win, Ctrl+\ on unix).
There is no interaction with the UI whatsoever. What the I/O is doing is reading in a list of files and writing their absolute pathnames to a text file. It is on a completely separate thread from the GUI.
The thread that is running responsible for painting in the JFrame may make a call during the I/O operation like:
System.out.println(System.currentTimeMillis());
And that will work; but, for some reason, the painting functions will not. The JFrame stays blank until the I/O operation ceases.
Are you calling repaint() with no arguments? If so, that actually just indicates to the AWT thread (running in the background) that the window should be repainted as soon as possible.
If you call repaint(long ms) where ms is the number of milliseconds that are “allowed” to pass before the repaint of the window occurs. Calling repaint(0) should force instant repaint.
However, if your I/O thread is running at full speed (i.e. no sleep() or yield()) then on some system it’ll block other threads altogether.
Kev
Whoops! ;D
As sure as I was yesterday that the I/O operation was being done on a totally separate thread, it turns out that I was wrong about that.
Thanks for the help, though. That repaint(0) call will definitely come in handy.
Anyway, I was making a program which writes the absolute pathname of each and every single file and folder inside a given directory to a specified text file. Works now.