Graphic2D.setBackground

J

Jenny

Hi,

Could you tell me why the code comp2D.setBackground(Color.white); does
not make the color white? The code comp2D.fillRect(0, 0, 400, 400);
works.


Thank you very much.



import java.awt.*;
import javax.swing.*;
import java.awt.geom.*;

public class Line extends JFrame {
public Line() {
super("Line");
setSize(410, 430);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
LinePanel lp = new LinePanel();
Container content = getContentPane();
content.add(lp);
setContentPane(content);
setVisible(true);
}

public static void main(String[] arguments) {
Line line = new Line();
}
}

class LinePanel extends JPanel {
public void paintComponent(Graphics comp) {
super.paintComponent(comp);
Graphics2D comp2D = (Graphics2D) comp;
comp2D.setBackground(Color.white);
// comp2D.fillRect(0, 0, 400, 400);
Line2D.Double l1 = new Line2D.Double(10,200,390,200);
Line2D.Double l2 = new Line2D.Double(200,10,200,390);
BasicStroke pen = new BasicStroke(5F);
comp2D.setColor(Color.blue);
comp2D.draw(l1);
comp2D.draw(l2);
}
}
 
P

Paul Lutus

Jenny said:
Hi,

Could you tell me why the code comp2D.setBackground(Color.white); does
not make the color white? The code comp2D.fillRect(0, 0, 400, 400);
works.

Your instruction to set the background white is simply a way to assign a
color for the next paint command. But the instruction is issued by code
*within* the paint command. The subsequent fillRect() call actually paints
with the chosen the color.

The setBackground command properly belongs in the main program, not in the
paintComponent() method.
 
T

Tor Iver Wilhelmsen [TeamB]

(e-mail address removed) (Jenny) writes:

As Paul said, but more explicitly:
super.paintComponent(comp);

This is the call that will actually paint the background.
comp2D.setBackground(Color.white);

But your white color is set here, after the background paints.

Solution: Call setBackground() in the constructor.
 
D

David Favro

A side topic that's bothered me for a long time...

Notice that this code blindly assumes that the Graphics object passed
into paintComponent() is, in fact, a Graphics2D. Since most
sophisticated drawing is much easier with a Graphics2D than a
Graphics, I usually do the same (except with an explicit instanceof
check, etc.), and it has always worked when running Swing apps under
1.4. But Sun's documentation, so far as I can tell, never explicitely
says that the Swing run-time environment WILL always use a Graphics2D
for component painting, so...

Does anyone know, when is it safe to assume that component painting
will take place with a Graphics2D? Is it implementation-specific?
Where is this documented? If the answer is "always", then why
wouldn't they use that type to pass in as the parameter to
paintComponent(), etc.? And if I were passed a Graphics that isn't a
Graphics2D, but I want to do my painting via a Graphics2D, do I have
any options, like an 'adapter' that translates Graphics2D calls and
passes them on to a Graphics? Should I cross-post this to c.l.j.gui?

Please post replies to the newsgroup -- this e-mail has been heavily
harvested for spam so I cannot pick the real messages out of the
flood.

TIA,
David Favro
(e-mail address removed)
Meta-Dynamic Solutions, LLC
 
D

David Favro

A side topic that's bothered me for a long time...

Notice that this code blindly assumes that the Graphics object passed
into paintComponent() is, in fact, a Graphics2D. Since most
sophisticated drawing is much easier with a Graphics2D than a
Graphics, I usually do the same (except with an explicit instanceof
check, etc.), and it has always worked when running Swing apps under
1.4. But Sun's documentation, so far as I can tell, never explicitely
says that the Swing run-time environment WILL always use a Graphics2D
for component painting, so...

Does anyone know, when is it safe to assume that component painting
will take place with a Graphics2D? Is it implementation-specific?
Where is this documented? If the answer is "always", then why
wouldn't they use that type to pass in as the parameter to
paintComponent(), etc.? And if I were passed a Graphics that isn't a
Graphics2D, but I want to do my painting via a Graphics2D, do I have
any options, like an 'adapter' that translates Graphics2D calls and
passes them on to a Graphics? Should I cross-post this to c.l.j.gui?

Please post replies to the newsgroup -- this e-mail has been heavily
harvested for spam so I cannot pick the real messages out of the
flood.

TIA,
David Favro
(e-mail address removed)
Meta-Dynamic Solutions, LLC
 
P

Paul Lutus

David said:
A side topic that's bothered me for a long time...

Notice that this code blindly assumes that the Graphics object passed
into paintComponent() is, in fact, a Graphics2D.

The cast is quite benign, and when it isn't, the compiler will complain
about it.
 
B

Babu Kalakrishnan

David said:
Does anyone know, when is it safe to assume that component painting
will take place with a Graphics2D? Is it implementation-specific?
Where is this documented? If the answer is "always", then why
wouldn't they use that type to pass in as the parameter to
paintComponent(), etc.? And if I were passed a Graphics that isn't a
Graphics2D, but I want to do my painting via a Graphics2D, do I have
any options, like an 'adapter' that translates Graphics2D calls and
passes them on to a Graphics? Should I cross-post this to c.l.j.gui?

If you're running under Java2, the Graphics context passed to you is
guaranteed to be an instance of Graphics2D object. I can't quite recall
where it is documented to be so - but I distinctly remember reading it
in some of Sun's documentation - could be the Java2D API guide. True that
they should have made it explicit in the API documentation of either the
AWT package or the java.awt.Component / javax.swing.JComponent classes.

The reason why the method signatures of most methods still specify
"Graphics" is in order to maintain backward compatibility with
JDK1.x programs (and the pre-Java2 versions of Swing) which expect
the argument passed to be of type "Graphics" and not Graphics2D).

And by the way, ignore the comment made by Paul (Lutus) who seems to
believe that the Java Compiler will catch all situations where a
ClassCastException can be thrown - I think you know better about it
anyway :)

BK
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top