JComponents won't show until I move mouse over them

[Flo Powers]

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!

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class Oppgave_12_17 extends JFrame 
   implements MouseListener, 
   MouseMotionListener,
   ItemListener,
   ActionListener
{
public JCheckBox drawRect, drawOval;
public JButton cmdClear;
private int type, store;
private int x1, y1, x2, y2;

public Oppgave_12_17()
{
super("Oppgave 12.17 ");
cmdClear = new JButton( "Clear" );
cmdClear.addActionListener(this);
drawRect = new JCheckBox("Draw Square: ");
drawRect.addItemListener(this);
drawOval = new JCheckBox("Draw Oval: ");
drawOval.addItemListener(this);
type = -1;

getContentPane().setLayout( new FlowLayout());
getContentPane().add(drawRect);
getContentPane().add(drawOval);
getContentPane().add(cmdClear);

addMouseListener(this);
addMouseMotionListener(this);

setSize(800, 600);
setVisible(true);
setResizable(false);
 
java.awt.Dimension cntr = 
java.awt.Toolkit.getDefaultToolkit().getScreenSize();
this.setLocation((int)((cntr.getWidth()/2) - (this.getWidth()/2)),
    (int)((cntr.getHeight()/2) - (this.getHeight()/2)));

}
 
public void mouseClicked( MouseEvent e ){}
public void mouseEntered( MouseEvent e ){}
public void mouseExited( MouseEvent e ){}
public void mouseDragged( MouseEvent e ){}
public void mouseMoved( MouseEvent e ){}

public void mousePressed( MouseEvent e )
{
if( type > 0 )
{
x1 = e.getX();
y1 = e.getY();
}
}

public void mouseReleased( MouseEvent e )
{
if( type > 0 )
{
x2 = e.getX();
y2 = e.getY();
int temp;
if( x1 > x2 )
{
temp = x1;
x1 = x2;
x2 = temp;
}
if( y1 > y2 )
{
temp = y1;
y1 = y2;
y2 = temp;
}
if( y1 < 65)
y1 = 65;
repaint();
}
}
 
public void itemStateChanged( ItemEvent e )
{
if( e.getStateChange() != ItemEvent.SELECTED )
type = 0;
else
{
if(e.getSource() == drawRect )
{
drawOval.setSelected(false);
drawRect.setSelected(true);
type = 1;
}
else if(e.getSource() == drawOval )
{
drawRect.setSelected(false);
drawOval.setSelected(true);
type = 2;
}
}
}

public void actionPerformed( ActionEvent e )
{
store = type;
type = 0;
repaint();
}

public void paint( Graphics g )
{
int width = x2 - x1;
int height = y2 - y1;
switch( type )
{
case 0: g.clearRect(0,65, getWidth(), getHeight());
type = store;
break;
case 1: g.drawRect(x1, y1, width, height);
break;
case 2: g.drawOval(x1, y1, width, height);
break;
}
}

public static void main(String[] args)
{
Oppgave_12_17 tegneProgram = new Oppgave_12_17();
tegneProgram.addWindowListener( 
    new WindowAdapter() 
    {
    public void windowClosing( WindowEvent e)
    {
    System.exit(0);
    }
    }
    );
}
}

[Jeff Albertson]

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:

public class Example extends JComponent {
    protected void paintComponent(Graphics g) {
        super.paintComponent(g);
        //do your drawing here:...
    }
}

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

[Craig Wood]

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

public void paint( Graphics g )
{
super.paint(g);
int width = x2 - x1;

[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'll try extending JPanel instead, and then insert an object of that type into my JFrame.

Thanks!

[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?

Thanks!

[Jeff Albertson]

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]

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]

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]

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]

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!