I am looking for the paint method implementation for a Java TextArea component (java.awt.TextArea).
I have read through the source code for the class as well as its super class (java.awt.TextComponent), but have not found a public void paint(Graphics g) method implementation, which I think means the class would be using the default Component#paint(Graphics) implementation, which doesn't make sense. Am I missing something here? How is a TextArea component painted?
TextArea is an AWT component, not a Swing component. It's thus what's called a heavyweight component, which means it's in fact implemented by a native component of the underlying platform/OS (i.e. a Windows/Gnome/Motif component, depending on the OS), called the peer of the component. The painting is thus done by the platform's native widget, and not by the component.
AWT Components is dinosauruses from last milenium, and only by back-compactible are there and still exists, please/better would be to change that to the Todays JComponents, all starts with "J" here is list of JComponents with tutorials, but for Swing's JComponents is there paintComponent(Graphics g) instead of paint(Graphics g)
method paint is still there but for deepest painting in XxxXxxUI, for example MetalButtonUI, but not for painting Image/Lines/Text ... and just try to avoid a similar examples from year 2000 and another very old examples, that's really wrong implemntation for Custom Painting in Java6's Swing,
here is your required tutorial and Java6 API
on this Forum are plenty threads about Painting Something in JComponents
EDIT: if you want to paint something then look for JLabel (is transparent by defalut), that best JComponent for 2D Graphics, examples for that here, and with paintComponent() method only
Related
What is the actual difference between paint(), paintComponent() and paintComponents() in Java Swing?
I tried to understand what explained in Oracle docs but I am not clear.
AWT, override paint().
Swing top-level container (e.g.s are JFrame, JWindow, JDialog, JApplet ..), override paint(). But there are a number of good reasons not to paint in a TLC. A subject for a separate question, perhaps.
The rest of Swing (any component that derives from JComponent), override paintComponent().
Neither override nor explicitly call paintComponents(), leave it to the API to call it when needed.
Be sure to also use #Override notation whenever overriding a method.
Doing so would hint at the problem of trying to override paintComponent(..) in a JFrame (it has no such method), which is quite common to see.
You may be interested in reading Painting in AWT and Swing
A quote:
The rules that apply to AWT's lightweight components also apply to Swing components -- for instance, paint() gets called when it's time to render -- except that Swing further factors the paint() call into three separate methods, which are invoked in the following order:
protected void paintComponent(Graphics g)
protected void paintBorder(Graphics g)
protected void paintChildren(Graphics g)
Swing programs should override paintComponent() instead of overriding paint(). Although the API allows it, there is generally no reason to override paintBorder() or paintComponents() (and if you do, make sure you know what you're doing!). This factoring makes it easier for programs to override only the portion of the painting which they need to extend. For example, this solves the AWT problem mentioned previously where a failure to invoke super.paint() prevented any lightweight children from appearing.
I am doing a project with double buffering. When I paint, it simply paints on top of the old layers, but I need to erase them. Repaint() didn't work, but I'm guessing something equally as simple is the answer.
Any ideas?
Added code, and now it disappears, but it erases the background color.
public void paint(Graphics g)
{
super.paint(buffer);
for(Projectile p: projectiles)
drawRectImage(buffer, p.image, p.getRectangle());
}
Suggestions:
If this is a Swing GUI, then don't override the paint method, but instead override the paintComponent method. This won't help your current problem, but will help prevent future problems including problems with painting of borders and child components.
If Swing (again you don't say), then make sure that your painting component extends JPanel, not JComponent, since JPanel is opaque and fills its background rectangle in its super method.
If it's not Swing, then you should strongly consider changing from AWT to Swing.
If you're still stuck, then yep, you'll want to create and post a minimal example program. Please check out the link.
I have a functioning Java applet which can be embedded into a web page and wish to now add some swing components for additional functions. However whenever I add a component like a JLabel, it simply does not appear on the viewport/canvas unless I remove my entire paint method. The latter option allows me to add swing components but naturally I then cannot render any shapes. It appears to resemble an eXclusive OR (XOR), either one but not the other.
Is there anyway in a native Java applet to add swing components and still maintain the paint(Graphics g) method. Please note that I am inheriting from Applet and not JApplet.
If you override paint method in applet then there is no simple way.
What you could do instead of overriding paint in applet.
Extend JComponent instead and do the custom drawing there.
create JPanel that contains all the needed swing components including the component from earlier step.
Add that panel to applet which is using default paint method.
I suggest that you add the components to a separate panel that doesn't override paint. By overridding paint, you are customizing the way the component is drawn, so the layout manager and the components it has to manage do not count, it's only the implementation of paint you wrote that dictates how stuff is rendered.
So, your applet would contain a panel with the components and a panel that does the custom painting.
At the end of your paint method, call super.paint(g).
I was able to visualise the components over the applet canvas by invoking
paintComponents(g);
Thus the components are thereafter painted AFTER the actual paint(Graphics g) method completes its epoch.
I'm trying to implement a simple window scale in java's swing library. The goal is simply to double the window height and width, and paint the window and each of its components in scale.
Here's an example of the code I'm using:
public class MyWindow extends JFrame {
...
public void paint(Graphics g) {
Graphics2D g2d = (Graphics2D) g;
g2d.scale(2,2);
super.paint(g);
}
}
The position and size for each my components in this window is set manually using setBounds with a null layout for the window.
When I actually run the program, what happens is that the first paint for the window seems successful-- everything is sized appropriately. Each subsequent repaint by the components, however, is neither twice the size, nor in the proper location. Here's what I mean:
As you can see, portions of the screen which have components that call repaint manually (the animating bits), don't seem to be using the Graphics2D scale of the JFrame. I looked in the source code, and tried overloading a few other methods (update and repaint, mostly), but all of them seemed to produce the same result. I further looked at the paint and repaint methods of the component and container classes, but they all seem to call a specified repaint of their parent. Shouldn't my Window be the "biggest" parent? If so, why haven't these repaint calls reached my Window?
My big question to you is, therefore: what repaint methods of the parent component do the child components call? Why aren't the calls properly routed to my JFrame's paint call? Is there any other (better) way that I can scale my window? Any and all help is appreciated!
As discussed in Painting in AWT and Swing: The Paint Methods, "Swing programs should override paintComponent() instead of overriding paint()." A common approach is to create a view by overriding paintComponent() in a JComponent (or subclass), as shown here. Let your view listen for changes to the game's model, as discussed here.
SwingUtilities.updateComponentTreeUI() should be used to change the Look & Feel, not update the view.
Use
javax.swing.SwingUtilities.updateComponentTreeUI(parentComponent);
when you need to make sure all of the parentComponents child component's look and feel are updated properly.
What is the actual difference between paint(), paintComponent() and paintComponents() in Java Swing?
I tried to understand what explained in Oracle docs but I am not clear.
AWT, override paint().
Swing top-level container (e.g.s are JFrame, JWindow, JDialog, JApplet ..), override paint(). But there are a number of good reasons not to paint in a TLC. A subject for a separate question, perhaps.
The rest of Swing (any component that derives from JComponent), override paintComponent().
Neither override nor explicitly call paintComponents(), leave it to the API to call it when needed.
Be sure to also use #Override notation whenever overriding a method.
Doing so would hint at the problem of trying to override paintComponent(..) in a JFrame (it has no such method), which is quite common to see.
You may be interested in reading Painting in AWT and Swing
A quote:
The rules that apply to AWT's lightweight components also apply to Swing components -- for instance, paint() gets called when it's time to render -- except that Swing further factors the paint() call into three separate methods, which are invoked in the following order:
protected void paintComponent(Graphics g)
protected void paintBorder(Graphics g)
protected void paintChildren(Graphics g)
Swing programs should override paintComponent() instead of overriding paint(). Although the API allows it, there is generally no reason to override paintBorder() or paintComponents() (and if you do, make sure you know what you're doing!). This factoring makes it easier for programs to override only the portion of the painting which they need to extend. For example, this solves the AWT problem mentioned previously where a failure to invoke super.paint() prevented any lightweight children from appearing.