Hello guys, I'm trying to make an application that produces multiple moving circles. I have 3 classes, an Orb class that creates and animates the circle, a mainFrame class that works as a container for the circles, and a masterClass class that works as the main class.

The problem that I've been having is that whenever I try to instantiate more than one "Orb" object, Java only instantiates the last one. Can anyone please help me understand why this is and help me fix this? I have a feeling that it has something to do with the Graphics but I don't know how to tackle the problem.

JFrame (or actually its contentPane which you are in fact adding your components to) uses BorderLayout by default. And if you add a component to a BorderLayout-using container without also specifying a BorderLayout constant, then that component gets added to the Container BorderLayout.CENTER, replacing anything added previously BorderLayout.CENTER. So, one thing to possibly do is to give the JFrame's contentPane a different layout manager.

Other issues:
* I'm cringing when I see synchronized as a modifier of your paintComponent method and I'm absolutely sure that it's not necessary. Get rid of it.
* If you want moving circles that are all in the same frame, then I wouldn't have your orb class extend JPanel but rather just give orb the logic behind your moving objects (position field, ability to change position randomly) and drawing code (a draw or paint method that accepts a Graphics object and lets the Orb object draw itself).
* Then create a JPanel that holds an ArrayList<Orb> and add your Orb objects to the JPanel. In the JPanel's paintComponent method, iterate through the array list and tell each Orb object to paint itself.
* Each class/object only needs one Random object, and you would not re-create this object inside of any loop or run method.
* I think that your background threading will work but many of us would try to do this with a Swing Timer first.

11-25-2010, 02:26 PM

m00nchile

Quote:

Originally Posted by Fubarable

* If you want moving circles that are all in the same frame, then I wouldn't have your orb class extend JPanel but rather just give orb the logic behind your moving objects (position field, ability to change position randomly) and drawing code (a draw or paint method that accepts a Graphics object and lets the Orb object draw itself).

This is one thing I used to do as well, untill a course I took this year at my uni. There, one of the assistant professors has shown us a different organisational paradigm that is closer to the MVC principle, where objects know their state and know how to respond to input (the model and controller part) and a central rendering class takes care of all the drawing work (the view part). It does make sense in the sense, if you let the object draw itself, it doesn't know how to draw itself in the context of the scene it is part of. Now, as long as projects are small and mainly of a learn/test nature, these things don't matter too much, but I just thought I'd throw it out there. Also, the guy who showed this to us knows what he's talking about, he used to write articles for a gaming magazine and ported XNA to objective c with the use of OpenGL instead of DirectX, making it usefull for making graphic applications for Apple handhelds. So all in all, I trust his judgement in this :D