Thread.sleep?

[Piet den Dulk]

Dear Java Masters,

I have a backtracking method which calculates all the posibillities. but
when one solution I call the repaint method. Then the gui must be repainted
and there must be some delay so that the user should be able to see what the
solution is. So I've put a Thread.sleep(2000) in the paint method. But my
problem is that the backtracking method calculates the next solutions at the
moment when I call the sleep. This is nog what I want.

Is there a simple tric so I could let sleep the system 2000 instead of only
a thread so that the backtracking also sleeps.

Best regards,
Piet den Dulk

 

[Chris Smith]

I have a backtracking method which calculates all the posibillities. but
when one solution I call the repaint method. Then the gui must be repainted
and there must be some delay so that the user should be able to see what the
solution is. So I've put a Thread.sleep(2000) in the paint method. But my
problem is that the backtracking method calculates the next solutions at the
moment when I call the sleep. This is nog what I want.

Is there a simple tric so I could let sleep the system 2000 instead of only
a thread so that the backtracking also sleeps.

No.

I'd suggest you approach this from a different perspective. You see,
you've really gotten this whole thing backwards. If you're calculating
in one thread and displaying in the AWT event thread (and repaint makes
the switch from one the another), then it's the calculation thread that
you want to put to sleep. You definitely to NOT want the event thread
to sleep, because then leaves you with two second where your application
is completely unresponsive. (For example, if another window is dragged
over this one, your window won't repaint itself... leaving a white
"trail" for two seconds where the other window was dragged.)

So how about just having your computation thread sleep instead of doing
the sleeping in paint? That would avoid the broken UI code that makes
your program look cheap and slow... and it would also cause the
computation to occur when it should.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

So how about just having your computation thread sleep instead of doing
the sleeping in paint? That would avoid the broken UI code that makes
your program look cheap and slow... and it would also cause the
computation to occur when it should.

A rather more complicated solution might be even better. If the OP uses a
queue between the AWT thread and the thread that is generating solutions, then
the AWT thread can ensure that each solution is displayed for at least 2
seconds (or whatever) without normally holding up the solution finder.

If solutions are relatively rare then that would speed up the whole process,
and if they are relatively common then a bounded queue would at least provide a
nice abstraction for starting and pausing the generator thread.

Though I have to add that, without knowing the application, it sounds as if a
scrolling window of the solutions that have been found so far would work better
as a UI. That would allow the users to read the solutions at their own pace
with no need to pause anything.

-- chris

 

[Piet den Dulk]

Thank you Chris and Chris.

I've sure leared a lot more about java. Right now I've put the sleep in my
recursive method. and the drawing there too with a getGraphics. Unfortunetly
still have the problem with the drag window over the applet but I leave it
just this way cause I'm not a tallented programmer nor a java expert. But I
know a lot more right know.

Best regards,
Piet den Dulk

 

[Chris Smith]

Thank you Chris and Chris.

I've sure leared a lot more about java. Right now I've put the sleep in my
recursive method. and the drawing there too with a getGraphics. Unfortunetly
still have the problem with the drag window over the applet but I leave it
just this way cause I'm not a tallented programmer nor a java expert. But I
know a lot more right know.

That's not a hard problem to solve, and you're forming very bad habits
for future development. Just move the graphics code back to
paint/paintComponent, continue to call repaint when the screen needs to
change, and leave the Thread.sleep call in your recursive method. Let
us know how that turns out.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Piet den Dulk]

Dear Chris,

Thank you for your concerning. I shall try again your advice. Because I
really want to be a good programmer and take your advice in advance.

When I try to put the Thread.sleep in the recursive call and put a repaint
statement after or before the thread.sleep it only calls paint after the
whole recursion is done. I don't understand why it just not repaints the
screen at that moment. So I want that when one solution is found the
computer needs to repaint it right away and then it goes back to the
recursion and tries to find another one and then repaints it again over and
over again until there are no solutions anymore. Why is it that it repaints
the screen after the whole rucursion is done?

Piet den Dulk

 

[Chris Smith]

When I try to put the Thread.sleep in the recursive call and put a repaint
statement after or before the thread.sleep it only calls paint after the
whole recursion is done. I don't understand why it just not repaints the
screen at that moment. So I want that when one solution is found the
computer needs to repaint it right away and then it goes back to the
recursion and tries to find another one and then repaints it again over and
over again until there are no solutions anymore. Why is it that it repaints
the screen after the whole rucursion is done?

I can think of a couple possibilities. First, it's possible that you
only think you have two threads, and actually are doing your calculation
in the event dispatch thread. Second, you might be using
synchronization too liberally and effectively forcing the painting
thread to wait for you to finish the computation.

The best way for me to figure out which is happening would be for you to
post your code. Before posting, you'll probably need to remove the
parts that aren't relevant to the problem, and then test to be sure the
problem is still happening before you post. (Incidentally, if you
remove what you thought was irrelevant and it fixes the problem, then
that's interesting information as well.)

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Piet den Dulk]

Dear Chris,

Thank you. I now see that the problem is with the evenHandler. It first
needs to end the actionPerformed to repaint the screen. I did not understand
before. Sometimes you're missing the small parts of programming which makes
it dificult.

I just made a simple test to understand. I only call a repaint in the
actionPerformed method and a sleep. I now see that it first needs to fully
end the actionPerformed method.

my code is something like this:

actionPerformed(action e) {
(e.getSource()==button) {
findSolution(v);
}
}

findSolution(Vector v) {
if(solutionFound) {
Thread.sleep(2000);
repaint();
}
else {
findSolution(v);
}
}

But the simple test like this shows me that it first needs to end the
actionPerformed and then repaints it:

actionPerformed(action e) {
(e.getSource()==button) {
repaint();
for(int i=0; i<9999; i++) {
System.out.println(number:" + i);
}
}
}

Is it possible to repaint it while the actionPerformed is still runing. It's
annoying that you have to wait when it's finished.

best regards,
Piet den Dulk

 

[David Zimmerman]

Is it possible to repaint it while the actionPerformed is still runing. It's
annoying that you have to wait when it's finished.

The same piece of code that called your event handler, once you return,
is the one that will notice the repaint event and call the paint event
handler (ie paint()). If you don't return, there's noone to handle the
repaint event.

 

[Chris Smith]

But the simple test like this shows me that it first needs to end the
actionPerformed and then repaints it:

actionPerformed(action e) {
(e.getSource()==button) {
repaint();
for(int i=0; i<9999; i++) {
System.out.println(number:" + i);
}
}
}

Yep, that's the case.

Is it possible to repaint it while the actionPerformed is still runing. It's
annoying that you have to wait when it's finished.

Yes, it's possible. But it's a bad idea. It's a bad idea because it's
not *just* repainting your changes that you've blocked by taking up the
AWT event thread. It prevents youre application from processing any
kind of events at all; including all repaint requests (which sometimes
come in from the system instead of your application) and any other
events you might want to respond to.

So generally, you can get simple applications working this way, but the
whole technique becomes unworkable when you start adding requirements.
Any kind of event-base processing is completely unworkable while you're
hogging that thread.

So the solution is to use a new thread. That allows the event thread to
go about its business while your app works on its own tasks. The only
trick is that only the event thread is capable of calling most GUI code.
Thus, you need a way from your new thread to do the occasional short
task back in that event thread. EventQueue.invokeLater (in the
java.awt.EventQueue class) provides that missing tool, and you're ready
to go. The transformed code looks like this:

public void actionPerformed(ActionEvent e)
{
new Thread(new CountTask()).start();
}

private static class CountTask implements Runnable
{
public void run()
{
for (int i = 0; i < 9999; i++)
{
System.out.println("number:" + i);
}

EventQueue.invokeLater(new Runnable() {
public void run()
{
repaint();
}
});
}
}

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Piet den Dulk]

Thanks a lot. A really apreciate all your help. I sure have learned a lot
more about this newsgroup discussion.

regards,
Piet den Dulk