One Frame has the focus but is the other frozen?

[Dan Kempten]

I'm looking at an example from the Java Tutorial on page

http://docs.oracle.com/javase/tutorial/uiswing/components/list.html#creating

It shows how to use the Swing JList listBox , or rather professes to show...

Basically ListDialogRunner builds a frame and holds the main() and calls ListDialog (with a frame) which holds the focus until it is closed.


In the ..Runner static class (which contains the main()) it calls a static function in ListDialog class, a normal non-static class.
This static function then calls the private (!!!) constructor of ListDialog and the second window pops up.

Only when the second window is closed and returns a string does the code in ..Runner continue to march.

Seems to me a very strange way.

What do you think of ..Runner calling up the second window the normal way, using
a public constructor in ListDialog and then upon closing, sending the string value back to ..Runner to be displayed in the ..Runner frame?

1. This way, if ..Runner gives birth to this new frame/class (with a public new) is a second seperate thread formed for ListDialog and
is ..Runner still able to react to buttons pushed on its frame with its own thread.

OR

2. is giving birth to a new class from ..Runner actually handing the one and only thread in the world to the new frame/class and leaving ..Runner in a state of suspended animation?

[Steve Luke]

This is what is called a 'Modal Dialog'. It is used in cases where the child window must provide results to the caller, and the caller can not or should not proceed until the child has finished its work. In the ListDialogRunner example, the purpose of the dialog is to choose a name. when the user presses the button they expect to get a String that is displayed. it would make no sense for the Runner to continue without getting a String... what would it display? How could the Runner continue to do its job? So the ListDialogRunner uses the modal dialog to make sure the user selects a name before continuing.

If what you want is to have multiple frames open at one time, then you would not use a Modal Dialog, but would rather use a normal JFrame.

Note that this doesn't really have anything to do with static methods and private constructors. The constructor is private because it was designed only to be called from the static method. It is a means of controlling who has access to the instances, and how it can be created. They want to control this because the code which uses the dialog doesn't really care about the dialog Object itself, it should just care about the results of displaying the dialog. so the dialog Object itself is hidden from the caller.

The static method is used as a convenient way of getting the modal dialog built without making the user worry about frames, or letting the reference to the actual dialog leak (possibly allowing the user to get into trouble) when the only thing the user (by user I mean the code which calls the ListDialog) really cares about is the return value.

The part that makes the dialog modal is the first line of the ListDialog constructor: super(frame, title, true);. the true value tells the dialog it is modal, and when made visible, should block until the dialog is made not visible.

[Dan Kempten]

Thank you Steve.

That is one of the clearest, most informative answers I've ever read here. I don't think you used the word 'implement' a single time.

P.S. Don't you think these examples from Oracle.com are unhelpful? I wanted an example of a listbox component and they swamp me with all this exotic code.


I ask for a steak in a restaurant and they trample me with a herd of 50 steers.

If I ask to see an example of a shower curtain, they hand me a 20-floor Hilton Hotel as an example. It always takes a while to find the bathrooms.