Please do not top post.

You could say that. ActionEvents as well as painting occur in the same
thread - i.e the EventDispatchThread. When you close the dialog, it
doesn't go and automatically repaint all the regions first before
continuing with the statement after the setVisible(false) (or
dispose()), but just queues a repaint on the area just needs repainting.
The actual repainting will be done only at the time that it processes
all paint events (this allows it to combine multiple repaint requests
which may have occurred on the component into a single paint).

If you block the EDT by performing a time consuming task, the paint can
obviously take place only after you have finished the task : the reason
why you see the "shadow". The important thing to remember when workin
gunder AWT/Swing is that you should never perform any time consuming
tasks under the EDT, and should do these in a separate thread.

BK

Yes, exactly.  No events are processed while your process is running.

Events are processed / dispatched by the event dispatch thread, which runs
a simple loop that just pulls an event from the event queue and dispatches
it.  Paint events are placed on this queue, and they are dispatched by
calling your component's paint() method.  Action events created when one
of your component's buttons are pushed are also placed on this queue, and
they are dispatched by calling your listener's actionPerformed() method.
The obvious implication of this is that no painting will occur until your
actionPerformed() method returns.
       
Modal dialogs are different - basically what happens there is that, when a
modal dialog is shown, it starts a new event loop, inside the setVisible()
method.  That is why you do not need to return from your actionPerformed()
method before the modal dialog can be painted.

There is some very good material covering this in The Java Tutorial on the
Sun web site (http://java.sun.com/docs/books/tutorial/index.html).  I
would definitely recommend that you take a look at this, especially the
trails, "Essential Java Classes" and "Creating a GUI with JFC/Swing".

I am quite sure that will not work.  Paint events have a low priority, so
the event posted with invokeLater() will be processed before any paint
events.

Have you actually tried doing this?  If you really think this will work,
would you please post a runnable example that demonstrates how it works?

If you really wanted to do something like this, you could force the dialog
to paint by calling paintImmediately() on the dialog's content pane.  But
that would only deal with the initial dialog exposure.  If the dialog were
covered and then exposed by some other window during the long process, it
would not repaint.  The only *correct* way to handle long-running
processes under Swing/AWT is to run them in a separate thread.

May I suggest the following:

(a) You stop top-posting. The group's FAQ contains references to a
number of resources regarding proper newsgroup behavior. You might want
to check them out. Of course, you can ignore them, but this
significantly reduces your chance of getting an answer here.

(b) Please read

    http://java.sun.com/docs/books/tutorial/uiswing/index.html

from the first to the last page. A newsgroup is not a good substitute
for learning a GUI toolkit. People will sooner or later get angry at you
if you don't do your homework and learn the basics.

(c) After (b), please at least browse through

    http://java.sun.com/docs/books/tutorial/2d/index.html

because these issues usually come up sooner or later, too.

(d) The FAQ points to a number of TSC papers, regarding Swing's painting
mechanism and architecture. You might want to give them a quick look,
too. So in case you need background information you know where to find it.

/Thomas