Waiting for a dialog in ctor

[Philipp]

Hello
I have a class DataHolder which represents some data and loads it from a
file using its constructor.
The caller code would look like
DataHolder d = new DataHolder(file);
useDataHolder(d);

Now I would like the user to be able to choose some options for the file
being loaded. So inside the DataHolder ctor, I would like to show a
Dialog and _wait_ for it to return. And then get some params from that
Dialog and finish the construction of my DataHolder object.

Now I'm a bit confused on how to do that.

For now the constructor lools like:
public DataHolder(File file){
someStuff();

ParamDialog dialog = new ParamDialog(); // is a JDialog
dialog.setVisible(true);
Param p = dialog.getParam();

otherStuff(p);
}

the code will execute fine but if I'm correct the thread (AWT) will just
continue while the dialog is shown. So Param p is not yet the final
value and otherStuff(p) will be corrupted.

How should I do this?

Thanks for your answers
Philipp

 

[Andrew Thompson]

Philipp wrote:
..

...inside the DataHolder ctor, I would like to show a
Dialog and _wait_ for it to return.

See..
<http://java.sun.com/javase/6/docs/a...lusionType(java.awt.Dialog.ModalExclusionType
)>
..as well as the constuctors that mention 'modal'..
<http://java.sun.com/javase/6/docs/api/javax/swing/JDialog.html#constructor_detail
A JOptionPane might also be suitable.

HTH

 

[Philipp]

Philipp wrote:
.

See..
<http://java.sun.com/javase/6/docs/a...lusionType(java.awt.Dialog.ModalExclusionType
)>
.as well as the constuctors that mention 'modal'..
<http://java.sun.com/javase/6/docs/api/javax/swing/JDialog.html#constructor_detail

Thanks a lot! That works perfect.

(I didn't know that "modal" was also stopping the execution of the
caller code, I thought it was just focus management, so I didn't even
try it)

Philipp

 

[Eric Sosman]

Philipp wrote On 04/10/07 01:49,:

Hello
I have a class DataHolder which represents some data and loads it from a
file using its constructor.
The caller code would look like
DataHolder d = new DataHolder(file);
useDataHolder(d);

Now I would like the user to be able to choose some options for the file
being loaded. So inside the DataHolder ctor, I would like to show a
Dialog and _wait_ for it to return. And then get some params from that
Dialog and finish the construction of my DataHolder object.

Perhaps the constructor should also defragment all the
file systems, search the Net for applicable patches and
apply them, scan for viruses, check some interstellar noise
for signs of intelligent life, and end world hunger.

;-)

In other words, it is possible to do what you ask (see
others' responses), but I think you are trying to do too
much work inside one constructor. A constructor that tries
to be all things to all people is likely to be extremely
hard to re-use in other programs, or to work well in newer
versions of your current program as you make changes. For
example, consider an enhancement: Let the user select the
processing options beforehand (perhaps via environment
variables or Preferences or some such), so the constructor
can run unattended without the user sitting around waiting
to click a bunch of buttons. If your DataHolder constructor
insists on putting up a dialog and won't proceed until it
gets an answer, this will be a difficult enhancement ...

Suggestion: Separate the gathering of parameters from
the construction of a DataHolder, so the call now looks like

Param p = getParametersViaDialog(file);
DataHolder d = new DataHolder(file, p);
useDataHolder(d);

With this arrangement it's easy to see how you'd go
about implementing the contemplated enhancement: You'd
just write methods to build a Param object from Preferences
or environment variables or whatever, and pass the Param
to the DataHolder constructor. The constructor can then
use all the information in the Param object without needing
to know whence it came: from a dialog, from Preferences,
from a message delivered by carrier pigeon, whatever. You
might even go as far as

Param p = getParametersFromEnvironment(file);
if (p == null) {
// no default info: ask the user
p = getParametersViaDialog(file);
}
DataHolder d = new DataHolder(file, p);
useDataHolder(d);

.... and observe that the "do one thing well" DataHolder
constructor fits smoothly into this scenario, too.

Look for natural lines of cleavage in your problem
space, and exploit them in your solution.

 

[Philipp]

Philipp wrote On 04/10/07 01:49,:

Perhaps the constructor should also defragment all the
file systems, search the Net for applicable patches and
apply them, scan for viruses, check some interstellar noise
for signs of intelligent life, and end world hunger.

;-)

In other words, it is possible to do what you ask (see
others' responses), but I think you are trying to do too
much work inside one constructor. A constructor that tries
to be all things to all people is likely to be extremely
hard to re-use in other programs, or to work well in newer
versions of your current program as you make changes. For
example, consider an enhancement: Let the user select the
processing options beforehand (perhaps via environment
variables or Preferences or some such), so the constructor
can run unattended without the user sitting around waiting
to click a bunch of buttons. If your DataHolder constructor
insists on putting up a dialog and won't proceed until it
gets an answer, this will be a difficult enhancement ...

Suggestion: Separate the gathering of parameters from
the construction of a DataHolder, so the call now looks like

Param p = getParametersViaDialog(file);
DataHolder d = new DataHolder(file, p);
useDataHolder(d);

With this arrangement it's easy to see how you'd go
about implementing the contemplated enhancement: You'd
just write methods to build a Param object from Preferences
or environment variables or whatever, and pass the Param
to the DataHolder constructor. The constructor can then
use all the information in the Param object without needing
to know whence it came: from a dialog, from Preferences,
from a message delivered by carrier pigeon, whatever. You
might even go as far as

Param p = getParametersFromEnvironment(file);
if (p == null) {
// no default info: ask the user
p = getParametersViaDialog(file);
}
DataHolder d = new DataHolder(file, p);
useDataHolder(d);

... and observe that the "do one thing well" DataHolder
constructor fits smoothly into this scenario, too.

Look for natural lines of cleavage in your problem
space, and exploit them in your solution.

Thanks. You are absolutely correct.
This was one of those "let's just hack in a dialog..." thing without
much afterthought...

Philipp