Getting a Swing Thread

[Trinithis]

How do I access the thread that is created by a swing window, such as an extension of JFrame, from within the thread that created the window?

For example, I have a method that does something like this that is executed from the main thread. I want to join() the frameThread with the currentThread:

//Part of a method that has been called
Thread currentThread = Thread.currentThread();
//Extraneous code here
MyFrame frame = new MyFrame();
//A new thread is created behind the scenes from the MyFrame object, which extends JFrame.
Thread frameThread = .......?
frameThread.join();
return frame.calculatedValue;

What I'm coding is something like JOptionPane.showInputDialog(), but instead of that, I coded a InputForm.createFormDialog(), which brings up a window with multipule text fields and returns a String array when submitted. Here's the static method:

public static String[] createFormDialog(final String[] labelTexts) {
	Thread thread = Thread.currentThread();
	InputForm form = new InputForm(thread, labelTexts); //InputForm only has private constructors.
	form.sleepCallingThread();
	return form.returnString;
	}

Because InputForm extends JFrame, it creates its own thread, and if I don't pause the thread that called the InputForm.createFormDialog(), then createFormDialog() will happily continue and return form.returnString, which happens to be null before a user submits his form.

My current solution involves sleeping the current thread while a certain bool is false. Then when the user clicks a submit button, the bool turns true and the currentThread is inturruped, whereupon the form.returnString is returned.

private void sleepCallingThread() {
	while(!formSubmitted) {
		try {
			callingThread.sleep(3600000);
		}
		catch(InterruptedException e) {
			return;
		}
	}
}

Even though this works, I'm not happy with my technique. I've tried synchronized/wait()/notify(), but as I don't know threads/monitors very well, I couldn't get it to work. So my next idea is to do something like: frameThread.join(), but my dilemma is how to even get access to the frameThread in the first place.



If you want to see my source code in txt:
http://trinithis.awardspace.com/InputForm/InputForm.txt
http://trinithis.awardspace.com/Inpu...tInputForm.txt

[Trinithis]

I figured out how wait() and notifyAll() work. I had thought you did thread.wait() instead of syncedObject.wait(). Anyway, since I got waiting to work, I guess I don't need to know how to get the swingThread anymore.

[Twey]

//A new thread is created behind the scenes from the MyFrame object, which extends JFrame.

You'd need to give MyFrame a property or method by which you could access the thread you've created.

[Trinithis]

Well, it's just that the thread is created behind the scenes by the javax.swing API. I've tried looking it up, but couldn't find out where swing objects store the thread they automatically create. The thread is called the "event dispatch thread."

Regardless, if you don't know the answer, that's fine because I got wait() to work.

[Twey]

Oh, last time I used Swing events were handled in the main thread, so you had to create another one to do anything resource-intensive. I guess I'm a little out of date :-\

[mwinter]

How do I access the thread that is created by a swing window ...

A Swing window doesn't create a thread. It might prompt the creation of the event dispatch thread if it doesn't already exist (I'd need to trace through all of the VM source code, which I don't have), but that's part of the guts of the VM that one shouldn't need to worry about.

As for accessing it, one cannot directly as far as I know. One can determine if the current thread is the event dispatch thread, and one can execute code in the event dispatch thread, but there's no simple method that will retrieve it. Of course, if one has code executing in said thread, the Thread.currentThread method will get a reference to it.

What I'm coding is something like JOptionPane.showInputDialog(), but instead of that, I coded a InputForm.createFormDialog(), which brings up a window with multipule text fields and returns a String array when submitted. ... Because InputForm extends JFrame, it creates its own thread, and if I don't pause the thread that called the InputForm.createFormDialog(), then createFormDialog() will happily continue and return form.returnString, which happens to be null before a user submits his form.

If you're creating a modal dialogue box, then subclass JDialog. The setVisible method blocks until the dialogue is hidden (another setVisible call) or destroyed; either would be accomplished from within the dialogue itself.

Oh, last time I used Swing events were handled in the main thread, so you had to create another one to do anything resource-intensive. I guess I'm a little out of date :-\

I think there may have always been the possibility that the main thread wouldn't be the event dispatch thread. There was a note a few years ago in the Swing tutorial trail about potential problems that could occur even if the main thread only performed GUI-related work during startup. As a result, the advice changed so that initialisation was always performed in the event dispatch thread:

public class MyClass {
    public static void main(String[] args) {
        javax.swing.SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                /* ... */
            }
        });
    }
}

For more information, see the Concurrency in Swing and Concurrency tutorials.