Swing components with special needs?

[Twisted]

Suppose I want to make a Swing component that contains objects that
need to show selection effects and control handles (e.g. resize or
rotate handles)? Or one that contains a child component, which paints
itself somehow, and needs to show an overlaying grid with one square
selected? How would this best be accomplished?

I can think of a couple alternatives:

* Override paint. Put paintComponent after paintChildren, and draw
selection related stuff in paintComponent; handles etc. appear in front
of children.
* Selection stuff gets added as children, which may present a
management headache but keeps paint from needing to be overridden.
* Something I haven't thought of yet.

In the first case, would one's paint override just be like this?:

public void paint (Graphics g) {
paintChildren(g);
paintComponent(g);
paintBorder(g);
}

or are there other things that should be done inside paint besides
these three calls? (And should they get a copy of the Graphics object,
rather than the same one passed to paint?)

The ideal thing would really be to have two layers, one for the
selection related stuff in front of one for the "real" children.

Also, should such a component subclass JComponent directly, or JPanel
or even JScrollPane or similar?

What do the experienced Swing programmers among you say?

 

[Thomas Hawtin]

Suppose I want to make a Swing component that contains objects that
need to show selection effects and control handles (e.g. resize or
rotate handles)? Or one that contains a child component, which paints
itself somehow, and needs to show an overlaying grid with one square
selected? How would this best be accomplished?

I can think of a couple alternatives:

* Override paint. Put paintComponent after paintChildren, and draw
selection related stuff in paintComponent; handles etc. appear in front
of children.

You could do something like that. IIRC, you'll need to switch optimised
drawing off.

* Selection stuff gets added as children, which may present a
management headache but keeps paint from needing to be overridden.

Headache is the important word in that sentence.

* Something I haven't thought of yet.

My initial reaction is to go for a JLayeredPane.

Also, should such a component subclass JComponent directly, or JPanel
or even JScrollPane or similar?

If you have child components that appear to the user as components, use
JPanel as accessibility will be correct. The commonly held belief that
JPanel automatically sets opaque is not true of all versions of all
PL&Fs. JScrollPane isn't going to be easy to extend in a meaningful manner.

Tom Hawtin

 

[Twisted]

So it's better to subclass JPanel (or JLayeredPane? Must investigate
that) and, if necessary, put it in a scroll pane as a child?

 

[Monique Y. Mudama]

The commonly held belief that JPanel automatically sets opaque is not
true of all versions of all PL&Fs.

Uhoh! Could you please elaborate?

 

[Thomas Hawtin]

Uhoh! Could you please elaborate?

The relevant setOpaque call comes from the PL&F, and is not set from
within the JPanel itself. IIRC, GTK on 1.5 is an example of a PL&F that
sets the opaque property to false. But not on 1.6.

When you set a JPanel as the content pane of a JFrame, technically you
should call setOpaque on it to avoid potential performance problems.

Tom Hawtin

 

[Monique Y. Mudama]

The relevant setOpaque call comes from the PL&F, and is not set from
within the JPanel itself. IIRC, GTK on 1.5 is an example of a PL&F
that sets the opaque property to false. But not on 1.6.

When you set a JPanel as the content pane of a JFrame, technically
you should call setOpaque on it to avoid potential performance
problems.

I did not know that. Thank you.