aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes JComponents won't show until I move mouse over them Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "JComponents won Watch "JComponents won New topic
Author

JComponents won't show until I move mouse over them

Flo Powers
Ranch Hand

Joined: May 12, 2004
Posts: 57
Hi, I've got a simple app that allows the user to drag up rectangles and ovals with the mouse. It works, except that the button and checkboxes don't show until I move the mouse over them. Guessing it has to do with the paint method. Any hints?

Thanks!

Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
It's generally a *bad* idea to sublass JFrame and override any of its paint methods. To give an artful analogy, JFrame is the frame, not the painting! Instead, define a component to do the painting and add that to JFrame's content pane. Usually, JComponent or JPanel is subclassed to do this:

[ March 29, 2006: Message edited by: Jeff Albertson ]

There is no emoticon for what I am feeling!
Craig Wood
Ranch Hand

Joined: Jan 14, 2004
Posts: 1535
By overriding the (Container) paint method in your JFrame class you have successfully broken into the mechanism that draws the JFrame and its child components to the screen. You can look this method up in the JFrame api to see what it does. (Scroll down to the section Methods inherited from class java.awt.Container and follow the link.) The call to super allows the swing painting system to continue on with its work of rendering the JFrame and its child components. You can then add in your custom graphics. The JFrame paint method can/will paint over the components, depending on how you use it. Sometimes this is what is needed. Jeff's suggestion will help avoid this complexity. So, after all that
Flo Powers
Ranch Hand

Joined: May 12, 2004
Posts: 57
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'll try extending JPanel instead, and then insert an object of that type into my JFrame.

Thanks!
Flo Powers
Ranch Hand

Joined: May 12, 2004
Posts: 57
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?

Thanks!
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
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.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
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.
Flo Powers
Ranch Hand

Joined: May 12, 2004
Posts: 57
Yes, just starting out with GUIs. Am reasonably familiar with OOP and data structures.

Wondering what book to use instead for GUIs. Any ideas? Good online sources?

Am a bit unsure when to use paint and when to use paintComponent.

Thanks!
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Perhaps someone else can recommend a Swing text. I find Sun's tutorial as good an introduction as any book: http://java.sun.com/docs/books/tutorial/uiswing/index.html

As for paint/paintComponent:

In Swing, method paint is overridden to call the following subroutines, in order:
1.paintComponent
2.paintBorder
3.paintChildren
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.
Flo Powers
Ranch Hand

Joined: May 12, 2004
Posts: 57
Yeah, after looking at Sun's tutorial, I'm starting to get it. It pays off to do things right from the start - kind of like building a house - if the initial design is faulty, you're setting yourself up for trouble later.

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.

Thanks!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JComponents won't show until I move mouse over them