// This is supposed to show a modal dialog and then hide it again. In practice,
// this works about 75% of the time, and the other 25% of the time, the dialog
// stays visible.
// This is on Ubuntu 10.10, running:
// OpenJDK Runtime Environment (IcedTea6 1.9) (6b20-1.9-0ubuntu1)
// This always prints
// setVisible(true) about to happen
// setVisible(false) about to happen
// setVisible(false) has just happened
// even when the dialog stays visible.
package modalproblemdemo;
import java.awt.Frame;
import javax.swing.JDialog;
import javax.swing.SwingUtilities;
public class Main {
public static void main(String[] args) {
final Dialogs d = new Dialogs();
new Thread() {
@Override
public void run() {
d.show();
d.hide();
}
}.start();
}
static class Dialogs {
final JDialog dialog;
public Dialogs() {
dialog = new JDialog((Frame) null, "Hello World", /*modal*/ true);
dialog.setSize(400, 200);
}
public void show() {
SwingUtilities.invokeLater(new Runnable() { public void run() {
dialog.setLocationRelativeTo(null);
System.out.println("setVisible(true) about to happen");
dialog.setVisible(true);
}});
}
public void hide() {
SwingUtilities.invokeLater(new Runnable() { public void run() {
System.out.println("setVisible(false) about to happen");
dialog.setVisible(false);
System.out.println("setVisible(false) has just happened");
}});
}
}
}
It is clearly some sort of race condition. I don't think it is as simple as Erick Robertson's answer. Dialog's show()
code is quite complicated, it contains some special logic for being called from the event dispatch thread and it also posts events to the event queue. Maybe the order in which events are posted is somehow affected by thread delays.
Perhaps what you need is As Skip Head pointed out, invokeAndWait will block until the dialog is closed.SwingUtilities.invokeAndWait()
, this way you guarantee that setVisible(true)
has finished execution before you call setVisible(false)
.
And why do you need it anyways?
EDIT: This is my scenario of what's happening:
setVisible(true)
eventEDIT2: Looks like ProgressMonitor has the functionality you are trying to implement.
So it turns out that what happens when you show()/setVisible(true) a modal dialog is that a second event dispatch loop is run within the call to show/setVisible. Which makes perfect sense once you know about it. With that in mind, I ended up with this code:
public void runBlockingTask(final String taskName, final BlockingTask bt) {
SwingUtilities.invokeLater(new Runnable() { public void run() {
new Thread("Worker Thread: " + taskName) {
@Override
public void run() {
bt.run();
progressDialog.setVisible(false);
}
}.start();
}});
// NB This causes the event dispatch loop to be run inside this call,
// which is why we need to put everything after setVisible into an
// invokeLater.
progressDialog.setVisible(true);
}
You could try to dispose()
the dialog instead of hiding it, but that would require you to rebuild it if you wanted to show it again.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With