This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Murach's Python Programming and have Michael Urban and Joel Murach on-line!
See this thread for details.
Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

painting problems when resizing  RSS feed

Tauqueer Ali
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We have developed a component very similar to JavaHelp by Sun. We are also developing
an IDE and trying to integrate the help component with the IDE. Swing library and our own
library which has been extended from swing has been used extensively to develop these
A typical page in help component consists of TextField, our own class very similar to JTable,
JScrollPane and a few buttons.
When this help window is resized, it produces a lot of painting problems. For example the
same scroll bars appear 2-3 times side by side and the JButtons also show similar
It seems these components are being drawn without
erasing the previously drawn components.
I tried calling repaint from resize listener but it doesn't seem to work.
Unfortunately I can't share the code for this problem because its a private property of my
Some debugging pointers would be of great help.
Chantal Ackermann
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
do you really mean TextField or JTextField? mixing awt and swing can cause problems.
another reason could be that the layout is not configured properly - what layout are you using? GridBagLayout is powerful when it comes to resizing. it should not be necessary to call repaint() for resizing! if you want to change the components in the frame during runtime, use CardLayout or (with >1.4) setVisible(false/true) and validate().
yet another reason (and this seems most probably) is some or more methods that have a big impact on performance. this could be listener code that is "too heavy" (listener code should be fast and doing only what is really needed, and should cache data as much as possible). running the program through a profiler might be very helpful in this case.
generally: refactoring migth be a good point to start. reduce duplicate code, reduce method calls.
Nathan Pruett
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
These "duplicate" components aren't real components are they? They're just (how can I phrase this well...) "smears" left over from when the real component moved over that area. Right?

The "smears" basically come from an "invalid" area that can't be repainted. I can think of two reasons why this would happen. One is performance... something is taking a long time (perhaps custom resizing code?) and is locking up the ability of Swing to do the component repaint. Two, I have seen this problem in components that do custom painting and assume that their original size is the size they will be forever... they look fine until they resize, then they get "smears" around the edges because the component exists in the full area, but only a sub-section of the component is able to be repainted.
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!