Try putting a delay with Thread.sleep(20) between successive calls to move. The problem is that your calls to move the ball occur very quickly, maybe 0.1microsecond each, and the entire 200 movements are completed before the repaint() call has a chance to do anything. Remember Thread.sleep() declares a checked InterruptedException.
The code you're running is running in the Event Dispatcher Thread. This is also the same thread that will do the painting - but only after an event is completely handled. Therefore, you should never ever but lengthy operations in event handlers.
You'll need to create a new Thread which will do the loop for you, and then wrap the calls to repaint in EventQueue.invokeLater.
How this works: - worker.execute() creates a new Thread that executes doInBackground. - publish takes the arguments, puts them in a List, and then makes sure process is called on the Event Dispatch Thread. - when doInBackground is finished, done() is called on the Event Dispatch Thread again. This can be used to finish things up if needed.
So just call this code in your actionPerformed method, and it should work.
Also, Campbell is right about the sleep time. You have specified 1ms, whereas the human eye can only process around 24 frames per second (I believe). So everything below 40 will be hard to notice. You could still go for something lower but I wouldn't go below 20. [ August 31, 2008: Message edited by: Rob Prime ]
Originally posted by Beth Laguardia: Thank you all for the reply. I am not familiar yet with swing worker.. Is there any alternative aside from swing worker?
Yep, I'd actually use a Swing Timer here. It's easier to use than a SwingWorker, and since you don't have any resource-hungry blocks, I don't really see the need for a background thread at all (other than the behind-the-scenes background thread provided by Swing Timer).
You know, I didn't even think of the Swing Timer. Its tasks also have the advantage of running on the Event Dispatcher Thread so you just write an ActionListener that moves the ball, schedule it in the Timer and voila!
Joined: Feb 23, 2007
A couple of other recommendations: 1) Get rid of your "magic numbers" such as 300, 40, 400, 70. They will make it very hard to update and debug the program. Use constants and fields where you can. 2) You can get rid of the calls to g.setColor(Color.white); and g.fillRect(...) by simply adding a call to super.paintComponent(g) in your paintComponent method, and a call to drawPanel.setBackground(Color.white); in your "go" method. 3) Rather than have Bounce's methods directly manipulate BouncingBall's fields, it would be far better to create a constructor for Bounce that takes a BouncingBall object as a parameter and have your Bounce class call a public setYPosition(int yPosition) method. In my SSCCE my Bounce constructor's signature looked like this:
Joined: Oct 13, 2005
Good idea, Pete
Joined: Jun 01, 2008
Oh my! I am fairly new in java so I some of this i have not tackle yet but thanks to the reply..
I guess i will just stop beig mbitious and do not go to graphics yet.. hehe
But thank you all!
Joined: Oct 13, 2005
I think you ought to find a bouncing ball example which works and study it very carefully. It is a very common exercise, since it leads one into threading. Don't give up graphics, but take it slowly, because there is so much to learn very quickly.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com