JDialogs launched outside the Event-Dispatch Thread

M

Marcin Rodzik

Being aware of what has been said http://ow.ly/1I50n http://ow.ly/1I50J
I'd like to ask explicitly: what should I do if I want to display some
information to the user in a Swing GUI app using a JDialog? I know
dialogs are event-driven so that execution of the thread which
requested displaying the dialog stops, but other currently fired
events are still handled.

The thing I don't know and I'd like to is: should I create a Runnable
object and schedule it for execution:

SwingUtilities.invokeAndWait(new Runnable() {
@Override
public void run() {
/* display the dialog here */
}
});

or:

I can simply write the code like this:

JOptionPane.showMessageDialog(parent, msg, title, messageType);

without the SwingUtilities stuff and Swing will handle the code
correctly anyway? I used to follow the first option but now I doubt if
it makes any sense.

regards,
Marcin
 
L

Lew

Marcin said:
Being aware of what has been said <http://ow.ly/1I50nhttp://ow.ly/1I50J>
I'd like to ask explicitly: what should I do if I want to display some
information to the user in a Swing GUI app using a JDialog? I know
dialogs are event-driven so that execution of the thread which
requested displaying the dialog stops, but other currently fired
events are still handled.

The thing I don't know and I'd like to is: should I create a Runnable
object and schedule it for execution:

SwingUtilities.invokeAndWait(new Runnable() {
  @Override
  public void run() {
    /* display the dialog here */
  }

});

Usually the JDialog is raised in response to an event already on the
dispatch thread, but using invokeAndWait() or invokeLater() is fine if
you're already on the EDT.

I don't know why you'd prefer invokeAndWait() over invokeLater().
or:

I can simply write the code like this:

JOptionPane.showMessageDialog(parent, msg, title, messageType);

without the SwingUtilities stuff and Swing will handle the code
correctly anyway?

Only if you're already on the EDT to start with, otherwise it's a bad
idea.
I used to follow the first option but now I doubt if
it makes any sense.

Depends on whether you really mean for the caller to wait for the
dialog.
 
J

John B. Matthews

Marcin Rodzik said:
I know dialogs are event-driven so that execution of the thread which
requested displaying the dialog stops, but other currently fired
events are still handled.

Perhaps I misunderstand, but this seems incorrect. A modal dialog
blocks the caller's ability to post new user generated events to the
event dispatch thread (EDT), but the EDT itself continues to process
events. Based on this clarification,

<http://groups.google.com/group/comp.lang.java.programmer/msg/c6ddf50e2b6e1fa1>

this program would seem to be a counter-example:

I can simply write the code like this:

JOptionPane.showMessageDialog(parent, msg, title, messageType);

without the SwingUtilities stuff and Swing will handle the code
correctly anyway?

I would advocate this simpler approach, subject to the caveats adduced
by Lew in a related response.
 
D

Daniel Pitts

Being aware of what has been said http://ow.ly/1I50n http://ow.ly/1I50J
I'd like to ask explicitly: what should I do if I want to display some
information to the user in a Swing GUI app using a JDialog? I know
dialogs are event-driven so that execution of the thread which
requested displaying the dialog stops, but other currently fired
events are still handled.

The thing I don't know and I'd like to is: should I create a Runnable
object and schedule it for execution:

SwingUtilities.invokeAndWait(new Runnable() {
@Override
public void run() {
/* display the dialog here */
}
});

or:

I can simply write the code like this:

JOptionPane.showMessageDialog(parent, msg, title, messageType);

without the SwingUtilities stuff and Swing will handle the code
correctly anyway? I used to follow the first option but now I doubt if
it makes any sense.
SwingUtilities is old, use java.awt.EventQueue instead.

Yes, if you are not on the dispatch queue, you should use invokeAndWait
or invokeLater.
 
D

Daniel Pitts

Usually the JDialog is raised in response to an event already on the
dispatch thread, but using invokeAndWait() or invokeLater() is fine if
you're already on the EDT.

I don't know why you'd prefer invokeAndWait() over invokeLater().
invokeAndWait must *not* be called from the EDT.
One would prefer invokeAndWait if the caller wants to be sure the event
is fully processed before continuing.
Depends on whether you really mean for the caller to wait for the
dialog.
Which is a common (if misguided) idiom.

In view code, it makes sense, but if you put it in model/controller
code, you are likely to run into huge problems later.
 
M

Marcin Rodzik

Perhaps I misunderstand, but this seems incorrect. A modal dialog
blocks the caller's ability to post new user generated events to the
(.....)

Probably, what I said was ambiguous, but I didn't mean the EDT stops.
Indeed, it continues processing events. However, as far as I know, the
method which calls JDialog stops because the JOptionPane.showXxxDialog
methods don't usually return until the user presses some button, or
something. Am I right?

Anyway, thanks for *all* your answers. Now I know everything [I need]

MR
 
J

John B. Matthews

Marcin Rodzik said:
Probably, what I said was ambiguous, but I didn't mean the EDT stops.
Indeed, it continues processing events. However, as far as I know,
the method which calls JDialog stops because the JOptionPane.
showXxxDialog methods don't usually return until the user presses
some button, or something. Am I right?

Yes. The showXxxDialog() methods invoke show(), now deprecated, which
clarifies "It is permissible to show modal dialogs from the event
dispatching thread because the toolkit will ensure that another event
pump runs while the one which invoked this method is blocked."
Anyway, thanks for *all* your answers. Now I know everything [I need]
 
M

markspace

John said:
Yes. The showXxxDialog() methods invoke show(), now deprecated, which
clarifies "It is permissible to show modal dialogs from the event
dispatching thread because the toolkit will ensure that another event
pump runs while the one which invoked this method is blocked."


Also, the JDialog docs clearly state that JDialog is not thread safe.
Even though show() is an AWT method, the JDialog object is still
accessed on the EDT and therefore must be used in a thread-safe manner.

Call ALL of it's methods on the EDT only. show() has no documented
exception to this rule.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,808
Messages
2,569,684
Members
45,444
Latest member
JosefinaAb

Latest Threads

Top