SWING Multiple GUI

[David Kazkas]

Hi, I am run into the problems trying to create several SWING JDialog.

I have main JDialog with does have "Search" button. After this button is pressed some complex search is done which might take up to several minutes. While this is in progress I want to show "Please wait" dialog box on top of all open JFrame and JDialog. "Please wait" should be modal and not allow any kind of interaction with other opened windows.

If I make "Please wait" dialog (JDialog) modal it shows up and with text and loading image but actual search is not done. After this.waitingDialog.setVisable(true); no other code line is executed. This looks like blocking.

If I make this dialog ("Please wait") modeless the code after setVisible(true); is executed, but actual "Please wait" dialog is not initialized. You can see the right size box with title, but no text and loading animated gif running. It should up just after the whole search is done (just before closing "Please wait" dialog). Would be good, but it "Please wait" box don't have content and it's not modal anymore.

The search is done when button is pressed, so from inside of ActionListener.actionPerformed().

It's looks problem with threads. Any ideas how to accomplish my idea?

Thanks,
david

[Rob Spoor]

That's exactly what I did a while ago with my progress dialog. In short, you need a background thread to do the hard work, and notify the dialog when done. You can do this two ways:

1) using a regular Thread. The Runnable for the thread will be something like this:

Runnable runnable = new Runnable()
{
    public void run()
    {
        doHardWork();
        EventQueue.invokeLater(new Runnable()
        {
            public void run()
            {
                dialog.dispose(); // with dialog being a reference to your "please wait" dialog
            }
        });
    }
};
new Thread(runnable).start();
dialog.setVisible(true);

The hard work will be done in this background thread. When done, a request is sent to the Event Dispatcher Thread to dispose the dialog which will get rid of the dialog and make sure the dialog.setVisible(true) will no longer block.

2) similar but using a SwingWorker. The hard work is done in the doInBackground method, the disposing of the dialog in the done method:

SwingWorker<?,?> worker = new SwingWorker<Void,Void>
{
    @Override
    protected void doInBackground() // executed in a background thread
    {
        doHardWork();
    }

    @Override
    protected void done() // executed in the Event Dispatcher Thread
    {
        dialog.dispose();
    }
};
worker.execute();
dialog.setVisible(true);

[David Kazkas]

Prefect answer! Works just as I want.

Am is EventQueue.invokeLater(new Runnable() { ... } necessary, I think to you can dispose dialog in the same thread where the work is done just after the work.

What about this example:

    private void doSomeWork() {
        this.waitDialog.setVisible(true);
 
        Thread th = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(5000);
                } catch (InterruptedException ex) {
                    // do nothing
                }
 
                System.out.println("I am dead");
            }
        });
        th.start();
        try {
            th.join();
        } catch (InterruptedException ex) {
            System.out.println("Oh god...");
        }
 
        this.waitDialog.setVisible(false);
    }

I show the dialog box, I create and start thread with the work and after this thread is finished I hide dialog box. In this case I get blank dialog box, no content is visible in "Please wait" window. Maybe the join is making problems? Maybe content is never rendered because I block event dispatcher thread?

Just interested, haven't done much SWING programming.

david

[Rob Spoor]

The reason that the disposing (or hiding) is done using EventQueue.invokeLater (or SwingUtilities.invokeLater which just forwards the call to EventQueue) is because of how concurrency works in Swing. In short, unless mentioned otherwise (e.g. JTextArea.append), always make sure your interaction with UI controls are done in the EDT.

[pete stein]

David Kazkas wrote:Prefect answer! Works just as I want.

Am is EventQueue.invokeLater(new Runnable() { ... } necessary, I think to you can dispose dialog in the same thread where the work is done just after the work.

What about this example:

    //.....

I show the dialog box, I create and start thread with the work and after this thread is finished I hide dialog box. In this case I get blank dialog box, no content is visible in "Please wait" window. Maybe the join is making problems? Maybe content is never rendered because I block event dispatcher thread?

Answered in cross-post: cross-post with a custom example that I spent time creating.

OP, please don't have us waste time by cross-posting questions in multiple fora. Please read: BeForthrightWhenCrossPostingToOtherSites

[Rob Spoor]

And that is exactly why we have that policy. You now have two working examples given to you within one hour, both initially unaware of the other. If I had known about Pete's post I probably wouldn't have bothered posting my code. Now I just wasted my time.

[David Kazkas]

Hi,

Sorry for the cross-posting, at the time didn't know the rule. I am not very often visitor here. From now on, I will try following it.

@Rob Prime, you didn't waste your time. Multiple answers are good, this allows studying the problem deeper, discuss multiple possible solving solutions. I appreciate both for of you for effort.

Thanks,
david

[Michael Dunn]

> Multiple answers are good,

only if they're on the same forum.
people can then see what has already been suggested/tried, and post a possible alternative

what happens when posting to multiple forums is that the answers are often the same,
meaning at least one person has tried to help (often writing a test program to test a theory = time),
then this person clicks onto another forum, only to find that the problem was solved hours earlier in that other forum
(no exaggeration, this is a common occurrence).

now, how helpful do you think this person is likely to be when he sees another problem from the 'known' cross-poster?

I know what I do - next topic, couldn't care less whether the person with the problem gets a solution or not,
I know it's just not gunna come from me.