Board index » jbuilder » Any detail difference among "revalidate" "repaint" and "validate"?

Any detail difference among "revalidate" "repaint" and "validate"?

2003-10-26 11:46:23 AM
hello all:
I want to know where I can get detail info about
when and where to use "revalidate" "repaint" and "validate"?
In current my code, I use one rather the other just by trying.
I really want to get some underlying info for these.
thank you.
-Daniel Mark
=======I got some from web but it isn't enough ==============
Note that the last three functions may affect a row height and
call revalidate() at the end. It took me a while to figure out the
difference between validate(), invalidate() and revalidate().
Here's my understanding of them so far. invalidate() marks a
component and it's parent (and parent's parent) as dirty. It
doesn't actually update the screen. revalidate() simply queues
an invalidate() for a later time and get activated once all the
events in the queue have been handled. Good thing about revalidate()
is that you can call it multiple times and the invalidate() call placed
in the queue causes any prior invalidate() in the queue to be removed so
the component gets invalidated only once for a series of changes.
is really what updates everything and makes them valid. It is most often
for a container object which in turn validates all the contained

Re:Any detail difference among "revalidate" "repaint" and "validate"?

On 10/25/2003 at 10:46:23 PM, Daniel Mark wrote:
I want to know where I can get detail info about when
and where to use "revalidate" "repaint" and "validate"?
Probably the best place would be a good book on AWT and Swing. I can't
say that I have read a book that has a really good explanation of this
subject, and any that I did read are outdated and probably out of
print. I have heard that the two Core "Graphic Java" books are pretty
good, but I can't say for sure.
=======I got some from web but it isn't enough ==============
This is a reasonably accurate description, but I will expand on it a
little bit: Painting and Validating components are two very different
things, although they are some interactions between them.
The repaint() method just causes your Component's paint() method to be
called. You should generally call repaint() rather than paint()
because the painting subsystem schedules the paint() call at an
appropriate time and it coalesces multiple paint calls into one, where
appropriate. And in Swing, double buffering is tied to the painting
subsystem, so if you call paint() directly, you will bypass the double
When we say that a Component is "valid", that means that the
Component's coordinates (size and position) has been determined, and
nothing has changed that should affect those coordinates.
When Components are created, their "valid" property is false, so they
are deemed to be "invalid". They become valid by having their
validate() method called, either directly or indirectly. For
Containers, validate() will validate the container (if it is invalid)
by calling its doLayout() method, which typically will invoke the
LayoutManager. The validation is performed on the Container and
recursively on all of its child components, so an entire tree of
components will be laid out and will become valid. For Components that
are not Containers (e.g. AWT Components), the peer handles the
When you call invalidate() on a component, it marks the component as
being invalid, along with all of its ancestor containers up to the
nearest "validate root". In Swing, this is often the JRootPane within
the top-level window, but it can be any Container that does not change
size when its children do, such as a JScrollPane. Once a Component has
been marked as invalid, it can be validated by the validate() method.
Note that invalidating a component does not automatically cause it to
be validated. In plain-old AWT, you had to call validate() directly in
order to cause this to happen, which was a bit of a problem. If a
Component changed its state so that its size would change, it could
invalidate itself, but it could not reasonably cause the validation to
occur. There was no mechanism to keep track of the invalid Components,
so it was a very common bug to have components that were not validated.
This problem was solved with the revalidate() method in the Swing
JComponent class. This method calls invalidate on the the current
JComponent, but it also saves references to the invalidated components
and schedules an event that will perform a validate() on them.
Most Swing components will call revalidate() automatically when you
change an attribute that would affect their size and call repaint()
when you change an attribute that would affect their appearance.
However, if you are writing a custom component, you may need to make
these calls yourself. Calling validate() should not be necessary.
John McGrath [TeamB]
Before sending me e-mail, please read:

Re:Any detail difference among "revalidate" "repaint" and "validate"?

On 10/25/2003 at 10:46:23 PM, Daniel Mark wrote:

>I want to know where I can get detail info about when
>and where to use "revalidate" "repaint" and "validate"?
I can personally vouch for "Swing, Second Edition" (by Matthew Robinson,
Pavel Vorobiev, Pavel A. Vorobiev, David Karr) as an excellent book which
explains the differences between those methods, SPECIFICALLY in terms of
how they work *in* *Swing*. Here's an link for the book:
I use Swing "professionally" and it's been extremely helpful in answering
questions and educating me in general about Swing. Of the books on Swing
offered by Amazon, it's the one with the highest average customer rating.
But in particular, there's a section in the book that deals with these
issues: Section 2.11 "Painting and validation", talks about "Double
buffering", "Optimized drawing", "Root validation", "RepaintManager",
"Revalidation", "Repainting" and "Painting".
(I got that from the Table of Contents which is available via the page.)
Hope this helps,
Rich Wagner