in which thread shoud I use dialogs?

M

Marcin Rodzik

Hello,
An old Swing's rule says that all the UI operations should be carried
out in the event-dispatching thread, and other operations should be
done in other threads. I have written a GUI application which uses
multiple threads. Among them, there is a SwingWorker thread which can
inform user about an error, using a dialog for this purpose. Following
the aforementioned rule, I don't create the dialog in the SwingWorker
thread, but I put a new Runnable object in the Events' Queue.

In such context, I'm facing a great doubt: what if the dialog waited
for user's input? (some dialogs can do this, e.g. file chosers).
Wouldn't they blocked the event-dispatching thread?

regards,
Marcin
 
R

RedGrittyBrick

Marcin said:
Hello,
An old Swing's rule says that all the UI operations should be carried
out in the event-dispatching thread, and other operations should be
done in other threads. I have written a GUI application which uses
multiple threads. Among them, there is a SwingWorker thread which can
inform user about an error, using a dialog for this purpose. Following
the aforementioned rule, I don't create the dialog in the SwingWorker
thread, but I put a new Runnable object in the Events' Queue.

In such context, I'm facing a great doubt: what if the dialog waited
for user's input? (some dialogs can do this, e.g. file chosers).
Wouldn't they blocked the event-dispatching thread?

No. Swing dialogs (JDialog) are event driven, they don't block the event
dispatch thread (EDT) whilst waiting for user input.
 
M

Marcin Rodzik

No. Swing dialogs (JDialog) are event driven, they don't block the event
dispatch thread (EDT) whilst waiting for user input.

Is it the same for different (eg. colour, file...) choosers?
 
R

RedGrittyBrick

Marcin said:
Is it the same for different (eg. colour, file...) choosers?

If you are using Swing then the general rule is that any code that
updates the GUI must be run on the EDT. You should expect that *all*
Swing classes provided by Sun should work well when this rule is followed.

There are probably exceptions, but I'm sure most Swing programmers never
need be concerned about them.

Another way to think of this is to do everything on the EDT except for
time consuming operations that are not to do with GUI updating - for
example file or database I/O or time consuming mathematical
calculations. I think of the EDT as a foreground user-interface thread
and use SwingWorker to do other stuff in the background.

When constructing you JDialogs and other widgets, make sure that the
constructor only constructs. Do time-consuming initialisation in another
thread.

By following these simple rules you need never worry about blocking the
EDT. My advice is to follow these rules and only spend time worrying
when actual problems arise (which will be when you forgot to apply the
rules).

See
http://mindprod.com/jgloss/swingthreads.html
 
N

neuneudr

Is it the same for different (eg. colour, file...) choosers?

Well, if you're concerned about blocking the rest of your
app, then probably that you don't want to display , say, a
modal color chooser...

Modal windows done the way they usually are a retarded
Microsoftism :( If only all the other windows of your
app (the one you can't use anymore while the modal window
is there) became grayed out or something... But, no, modal
windows shall continues to confuse clueless users for ages.

Personally I display transient windows to my users :)
 
R

RedGrittyBrick

Well, if you're concerned about blocking the rest of your
app, then probably that you don't want to display , say, a
modal color chooser...

Modal dialogs don't block the EDT (which is what the OP said they were
concerned about).

Neither do they block execution in other threads of the application.
Other parts of the application can continue to update other parts of the
GUI.

AFAIK the only thing modal dialogs block is user input to other windows
of the same application.
 
A

Alessio Stalla

Modal dialogs don't block the EDT (which is what the OP said they were
concerned about).

Neither do they block execution in other threads of the application.

Modal dialogs do block the current thread when they are made visible,
so the OP's concern is sensible.
Other parts of the application can continue to update other parts of the
GUI.

But not on the same thread that made the dialog visible, until the
dialog is closed, afaik. It seems to me there's a contradiction: every
GUI operation should be done on the EDT, but JDialog.setVisible is
meant to be used on an application thread when the dialog is modal, to
simulate a "function call" that returns when the dialog is closed.
 
J

John B. Matthews

Peter Duniho said:

I couldn't resist. Happy Holidays!

package xmas;

import java.awt.AlphaComposite;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.EventQueue;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.LinkedList;
import java.util.Queue;
import java.util.Random;
import javax.swing.JFrame;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.Timer;

public class DialogTest extends JPanel implements ActionListener {

private static final int MAX = 64;
private static final String title = "Baubles";
private static final Random rnd = new Random();
private static final AlphaComposite ac =
AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 0.75f);
private final Timer timer = new Timer(100, this);
private final Queue<Bauble> queue = new LinkedList<Bauble>();

public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
@Override
public void run() {
JFrame f = new JFrame(title);
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
DialogTest dt = new DialogTest();
f.add(dt);
f.pack();
f.setLocationRelativeTo(null);
f.setVisible(true);
JOptionPane.showMessageDialog(dt, title);
}
});
}

public DialogTest() {
this.setPreferredSize(new Dimension(8 * MAX, 8 * MAX));
timer.start();
}

@Override
public void actionPerformed(ActionEvent e) {
if (queue.isEmpty()) {
for (int i = 0; i < MAX; i++) {
queue.add(randomBauble());
}
}
queue.add(randomBauble());
queue.remove();
this.repaint();
}

@Override
public void paintComponent(Graphics g) {
Graphics2D g2d = (Graphics2D) g;
g2d.setRenderingHint(
RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
g2d.setColor(Color.black);
g2d.fillRect(0, 0, this.getWidth(), this.getHeight());
g2d.setComposite(ac);
for (Bauble b : queue) {
g2d.setColor(b.c);
g2d.fillOval(b.x, b.y, b.d, b.d);
}
}

private Bauble randomBauble() {
int x = rnd.nextInt(this.getWidth());
int y = rnd.nextInt(this.getHeight());
int r = rnd.nextInt(MAX) + MAX / 2;
Color c = new Color(rnd.nextInt());
return new Bauble(x, y, r, c);
}

private static class Bauble {
private int x, y, d;
private Color c;

public Bauble(int x, int y, int r, Color c) {
this.x = x - r;
this.y = y - r;
this.d = 2 * r;
this.c = c;
}
}
}
 
Joined
Dec 31, 2009
Messages
6
Reaction score
0
hii,

hmmm multithreading ...

Code:
    public void playAfterEDT() {
        Runnable doRun = new Runnable() {

            public void run() {
                //anything what you want
            }
        };
        SwingUtilities.invokeLater(doRun);
    }

or

Code:
revalidate(); // add or change Swing rule(s) topLayContainer or with its component(s)
validate();
repaint()

nothing else ...

play with EDT and SwingWorker ---> before that please read Concurency API

... kopik
 

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

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top