Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How to capture a JComponent in java?  RSS feed

 
Dongolo Zsolt
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hy, i have this java code and i don't know how can i capture this component as an image and use that in the next step..in another class i have a colorchooser and it resets the draw area always..because of this i want to capture the draw area in every steps and call it for example in paint method..

 
Rob Camick
Ranch Hand
Posts: 2787
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Check out the Screen Image class for code to create a BufferedImage of any component.
 
Campbell Ritchie
Sheriff
Posts: 55284
156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And welcome to the Ranch
 
Fred Kleinschmidt
Bartender
Posts: 554
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't override paint(). Override paintComponent() instead, and be sure to call super.paintComponent(g) as the first statement. Otherwise borders and children (if any) will not be rendered properly.
 
Piet Souris
Rancher
Posts: 1939
66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in this case overriding 'paint' is acceptable, I think. Given the code, it is unlikely
that 'paintBorder' and 'paintChildren' are necessary. Clearing the component
to the background is needed, indeed, but that can be done with a simple 'g.fill'.

But I wonder: isn't it much simpler if Drawrea extends JPanel? Internally,
the pixels can be written to a BufferedImage, and the 'paintComponent'
of the panel simply draws that BufferedImage, even when a drag
is going on.
Add a method 'getImage' that returns the BI, for the cases that
you need it. It also has the advantage that there is no need
for a huge Point array. I would advise a List<Point> anyway.

However, special attention is needed when DrawArea is getting resized.
Since it is a JComponent, it is subject to the resizing policy of the
Layoutmanager of the container involved.

@Dongolo
have you thought about resizing aspects?
 
Fred Kleinschmidt
Bartender
Posts: 554
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that in this particular case overriding paint() might be ok, since the OP doesn't add a bo4rder or children. But one should get into the habit of doing it correctly so that if he ever does add a border it will be easy to do.

When I need something like this, I add a ComponentListener and re-create the BufferedImage appropriatlely.
 
Rob Camick
Ranch Hand
Posts: 2787
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But one should get into the habit of doing it correctly


I agree.

So many people override paint() because they find old code on the web that is used for AWT and don't realize that painting is done differently in Swing.

We should promote Swing painting techniques.
 
Piet Souris
Rancher
Posts: 1939
66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agreed.

My strategy would be to leave the BI intact. But that has
the consequence that some component pixels may not be
within the BI. But it is up to OP, of course, to decide
how to handle it. I was just curious, therefore I raised
the question.

Edit: agreed to Fred. However, on second thought:
as I argued, OP did in fact the correct thing. It is us
reacting like robots that we start about 'paintComponent'
and 'super.pC' and 'promote Swing painting techniques'.
Maybe OP simply knows better? Why did we not ask that
first?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!