[ March 29, 2006: Message edited by: Jeff Albertson ]
I'll try extending JPanel instead, and then insert an object of that type into my JFrame.
Originally posted by Flo Powers:
Yes, I have been reading a bit online about it, and was starting to get the idea I may be using the wrong book... I'm using Deitel and Deitel, 3rd ed. (1999), and the examples on drawing are consistently using the paint method directly on the JFrame object (or rather the class extends JFrame, and paints on itself).
I don't want to get in a flame war, but I hate every Deitel & Deitel book.
Originally posted by Flo Powers:
But wait - if I extend JPanel, put the button, checkboxe and radiobuttons in this class, and then stick an object of this type into a program that extends JFrame, where do I put the listener objects? In the main class that contains this extended panel object, or in the class that extends JPanel?
This design question should be asked no matter how you solve painting, right?
But first, an aside. I imagined the UI layout a bit differently. For example, the frame's content pane could use a BorderLayout with the drawing component in the center (and no components on top of it) and in the north or south of the content pane a toolbar or other container with your buttons etc on it. It seems a little strange to have the buttons directly on the drawing component -- do you want the buttons possibly on top of rendered shapes? But anyway, this is just a simple question of esthetics.
As for listeners, a lot of people get lazy and just stick them in the first place them think of, which is what your original design was. But let's be more careful here. Say your shape-drawing component is named ShapeCanvas. Should it implement, say, ActionListener? Definitely not! The fact that you are using a button to clear your surface is an implementation detail. What if you change it to use the keystroke ^X instead? Now, should it implement MouseMotionListener and MouseListener? Well, what's the job of this component? The primary job is to draw shapes. Listening to the mouse is secondary. One could imagine this component also drawing shapes whose bounds are read from a file. I'm also concerned when I see any component that implements listeners like that. What is to stop someone from adding this component as a mouse listener to an another entirely different component? I would write a separate class to do this mouse listening, but since you are just starting out, this might be too confusing because your design would become more complicated with additional classes.
As for paint/paintComponent:
In Swing, method paint is overridden to call the following subroutines, in order:
See the API for JComponent's paint method for more details.
When writing a custom component this order is usually correct, so it only the subroutines (and usually just paintComponent) that need to be overridden. Note that, if you were to override paint and forgot to call super.paint, any border the component had would disappear!
When you look around, you will see paint routinely overridden anyway. Why? That was the way to do it in the old AWT and many programmers have simply copied the older examples.
May as well go directly to the source to drink, so I'll be hanging out at java.sun.com for a while, instead of trying to tinker with a program based on a flawed design.