Using a method to return a value, that uses a modal dialog

[Ben Phillips]

I started work today on a custom modal dialog class, and started to write:

SomeClass select () {
setVisible(true);

and then realized that I had no apparent way of returning the result
from the method! It has to wait for the user to interact with the dialog
and select something, so I thought of figuring out some kind of
wait/notify thing ... but then realized that hanging the EDT to wait for
the user to input something will deadlock the app.

So it looks like I need to redesign to call select from a SwingWorker
rather than from the EDT, or to have select return void and accept a
callback object.

No problem, but this caused me to think about all the places littered
through the existing code where I call the integer-returning
JOptionPane.showOptionDialog(foo...) methods ...

I suppose those need to be moved to a SwingWorker too? Since the EDT
will just sit in some event listener or another waiting for an int to be
returned from the method, while the method waits for the EDT to produce
an action event for the user clicking an option button in the dialog...

Funny that the Java Tutorial doesn't mention anything about the trio of
non-void-returning JOptionPane static methods, the EDT, and concurrency,
given that I don't see how they could be implemented not to deadlock or
else blow chunks if called on the EDT.

 

[Owen Jacobson]

I started work today on a custom modal dialog class, and started to write:

SomeClass select () {
     setVisible(true);

and then realized that I had no apparent way of returning the result
from the method! It has to wait for the user to interact with the dialog
and select something, so I thought of figuring out some kind of
wait/notify thing ... but then realized that hanging the EDT to wait for
the user to input something will deadlock the app.

So it looks like I need to redesign to call select from a SwingWorker
rather than from the EDT, or to have select return void and accept a
callback object.

No problem, but this caused me to think about all the places littered
through the existing code where I call the integer-returning
JOptionPane.showOptionDialog(foo...) methods ...

I suppose those need to be moved to a SwingWorker too? Since the EDT
will just sit in some event listener or another waiting for an int to be
returned from the method, while the method waits for the EDT to produce
an action event for the user clicking an option button in the dialog...

Funny that the Java Tutorial doesn't mention anything about the trio of
non-void-returning JOptionPane static methods, the EDT, and concurrency,
given that I don't see how they could be implemented not to deadlock or
else blow chunks if called on the EDT.

They cheat. Sort of.

Modal dialogs and modal dialog pumps are nothing new. Windows and Java
implement modal dialogs the same way: by spinning off a new event pump
to handle the modal dialog while the main event pump is is blocked and
waiting for the dialog to close. JOptionPane is a convenience class
that provides some common modal dialogs and deals with getting data
into and out of their models for you, but you can also build your own
JDialog, give it a non-MODELESS modality type, and go to town.

The only real problem is that modal dialogs are user-hostile: they
take control over what to do next away from the user. It's usually a
better idea to do what you did in the first place, and pass along an
"on completion, do this" action to a non-modal dialog than it is to
block the whole UI waiting for the dialog, if you can manage it.
Practical example: Eclipse's non-modal Search is much easier to use
(you can switch back and forth between the search box and the text as
needed) than Notepad's thoroughly-modal Search feature, IMO.

-o

 

[Ben Phillips]

The only real problem is that modal dialogs are user-hostile: they
take control over what to do next away from the user. It's usually a
better idea to do what you did in the first place, and pass along an
"on completion, do this" action to a non-modal dialog than it is to
block the whole UI waiting for the dialog, if you can manage it.
Practical example: Eclipse's non-modal Search is much easier to use
(you can switch back and forth between the search box and the text as
needed) than Notepad's thoroughly-modal Search feature, IMO.

This is more like a save-changes dialog than a search dialog.

So int foo = JOptionPane.staticMethod() is safe on the EDT? It won't
deadlock?

If so, then it's likely that today's new UI code is free of any design
bugs. (Logic bugs is another matter. I guess it's testing time.)

 

[Ben Phillips]

This is more like a save-changes dialog than a search dialog.

So int foo = JOptionPane.staticMethod() is safe on the EDT? It won't
deadlock?

If so, then it's likely that today's new UI code is free of any design
bugs. (Logic bugs is another matter. I guess it's testing time.)

Working, but I have a new problem. I'll start a new thread.

 

[Ian Shef]

@aioe.org:

Funny that the Java Tutorial doesn't mention anything about the trio of
non-void-returning JOptionPane static methods, the EDT, and concurrency,
given that I don't see how they could be implemented not to deadlock or
else blow chunks if called on the EDT.

I have wondered a long time about this. The rule is to do everything that is
Swing related on the EDT, unless explicitly documented otherwise for a
specific method. I have not found any such exceptions for the non-void-
returning JOptionPane static methods, and yet how else are they to be used.
They could be used this way with some awkward gymnastics, but then what is
the point of the JOptionPane convenience?

I use the non-void-returning JOptionPane static methods without using
invokeLater or invokeAndWait. So do the Sun Java tutorials. So far, I
haven't observed any issues, but I wonder how much future trouble I am
causing for myself.

Is this a documentation shortcoming of JOptionPane?

 

[Ian Shef]

Come to a thread late much?

Yes, I am late and the rest of the thread is gone from my news server.
Sorry! I enjoy this group, but the volume is so high that I sometimes fall
waaaay behind.

The short answer is no, it's fine. There are no problems.

Pete

Thank you for the short answer, and for the longer explanation that followed.
I can sleep better now. I still think that the Javadoc for JOptionPane
should make this clear.

Currently (1.6), the Javadoc for JOptionPane just has:
"Warning: Swing is not thread safe. For more information see Swing's
Threading Policy" which says "All Swing components and related classes,
unless otherwise documented, must be accessed on the event dispatching
thread." Except for explanations in this news group, I haven't found the
"otherwise" yet. :-(

Thanks again!