We Keep Coding

JFrame-JDialog comunication

I have a JFrame main window wich has a Register button on in.Click the register button and the JDialog windows pops out.
public void mouseClicked(MouseEvent e) {
Reg new1=new Reg(users);
new1.setVisible(true);
}
The JDialog window has 2 buttons->Register,Cancel.Both of them must do something and close the Dialog window.
This is what I tried.
In the Reg(Dialog window)---> btnCancel:
public void mouseClicked(MouseEvent e) {
dialog.dispose();
System.out.println("Reg disposed by cancel button");
}
This closes the D window when run just the D window but I guess when executed from the main window(Button clicked) it still exists like an object in the main fraim"class" and doesn't close.What should I do ?How do I make it close ?

You need some way for the frame to determine how the dialog was closed
// Why are you using a `MouseListener` on buttons??
// User use keyboards to, use an ActionListener instead
public void mouseClicked(MouseEvent e) {
Reg new1=new Reg(users);
new1.setVisible(true);
switch (new1.getDisposeState()) {
case Reg.OK:
// Clicked Ok
break;
case Reg.CANCEL:
// Clicked cancel or was closed by press [x]
break;
}
}
Then in your Reg class, you need to maintain information about the state...
public class Reg extends JDialog {
public static final int OK = 0;
public static final int CANCEL = 1;
private int disposeState = CANCEL;
//...
public int getDisposeState() {
return disposeState
}
public void setDisposeState(int state) {
disposeState = state;
}
Then you change the state
// Why are you using a `MouseListener` on buttons??
// User use keyboards to, use an ActionListener instead
public void mouseClicked(MouseEvent e) {
setDisposeState(CANCEL);
dialog.dispose();
System.out.println("Reg disposed by cancel button");
}
This all assumes that your dialog is modal of course...
Now, having said all that, personally, I would make your Reg class a JPanel and add it to a JOptionPane instead or use a CardLayout
Take a look at:
How to Use Buttons, Check Boxes, and Radio Buttons
How to Write an Action Listeners
How to Make Dialogs
How to Use CardLayout
...for more details

JOptionpane + JDialog (non-modal) get the return value

I have a non-modal dialog with two input text fields shown with the JOptionPane with OK and CANCEL buttons. I show the dialog as below.
JTextField field_1 = new JTextField("Field 1");
JTextField field_2 = new JTextField("Field 2");
Object[] inputField = new Object[] { "Input 1", field_1,
"Input_2", field_2 };
JOptionPane optionPane = new JOptionPane(inputField,
JOptionPane.QUESTION_MESSAGE, JOptionPane.OK_CANCEL_OPTION);
JDialog dialog = optionPane.createDialog(null, "Input Dialog");
dialog.setModal(false);
dialog.setVisible(true);
How can i get the return value from the dialog? Means i need to get whether Ok or CANCEL button is pressed. How can achieve this?

One way would be to add a ComponentListener to the dialog and listen for its visibility to change,
dialog.addComponentListener(new ComponentListener() {
#Override
public void componentResized(ComponentEvent e) { }
#Override
public void componentMoved(ComponentEvent e) { }
#Override
public void componentShown(ComponentEvent e) { }
#Override
public void componentHidden(ComponentEvent e) {
if ((int) optionPane.getValue()
== JOptionPane.YES_OPTION) {
// do YES stuff...
} else if ((int) optionPane.getValue()
== JOptionPane.CANCEL_OPTION) {
// do CANCEL stuff...
} else {
throw new IllegalStateException(
"Unexpected Option");
}
}
});
Note: you should probably use the ComponentAdapter instead; I'm showing the whole interface for illustration.

Using getValue() will tell you how the dialog was closed. Since it's non-modal, you'll need to get that information once the dialog is closed, probably using a Thread that will wait that your dialog is closed to return the information. You don't give any details on what needs that information, so using another Thread might not be the best solution for you.

How do I make non-modal dialog whose setVisible blocks?

In a Swing (J)Dialog, setModal sets the modality - that is, whether the dialog should block input to other windows or not. Then, setVisible docs say for modal dialogs:
If the dialog is not already visible, this call will not return until the dialog is hidden by calling setVisible(false) or dispose.
Indeed, setVisible does return right away if the dialog is not modal. Sample code:
JDialog jd = new JDialog();
jd.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE);
/**
* If set to false, setVisible returns right away.
* If set to true, setVisible blocks until dialog is disposed.
*/
jd.setModal(false);
System.out.println("setting visible");
jd.setVisible(true);
System.out.println("set visible returned");
I want to make a dialog that doesn't block input to other windows, but still does block the caller. What is a good way to do this, now that setVisible doesn't block when the dialog is not modal?
Is there some rationale why setVisible's behavior depends on the modality?

I need to make a dialog that doesn't block input to other windows, but does block the caller so that I know when the dialog has been closed.
I usually solve this not by blocking the caller, but by using a callback of some sort - a simple interface that the dialog invokes when it's done. Let's say your dialog has an "OK" and a "Cancel" button and you need to distinguish which one is pressed. Then you could do something like this:
public interface DialogCallback {
void ok();
void cancel();
}
public class MyModelessDialog extends JDialog {
private final DialogCallback cbk;
private JButton okButton, cancelButton;
public MyModelessDialog(DialogCallback callback) {
cbk = callback;
setModalityType(ModalityType.MODELESS);
okButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
onOK();
}
};
cancelButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
onCancel();
}
};
// Treat closing the dialog the same as pressing "Cancel":
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
onCancel();
}
};
}
private void onOK() {
cbk.ok();
}
private void onCancel() {
cbk.cancel();
}
}
Then you just pass in an instance of DialogCallback to the constructor:
MyModelessDialog dlg = new MyModelessDialog(new DialogCallback() {
public void onOK() {
// react to OK
}
public void onCancel() {
// react to Cancel
}
});
EDIT
Is there some rationale why setVisible's behavior depends on the modality?
Well, that's just how how modal windows are supposed to work, no? A modal window should block the current workflow when displayed, and a non-modal/modeless should not. See e.g. the Wikipedia pages on modal windows or dialog boxes.

Just put this.setModal(true) but not set the parent dialog on the constructor:
MyDialog dlg = new JDialog();
this.setModal(true);
When you call setVisible(true), it wont stop

The direct approach is by:
JDialog dialog = new JDialog(owner, ModalityType.DOCUMENT_MODAL);

I have found another way to do this. In the constructor of my progress bar, which extends javax.swing.JDialog, I added:
setModalityType(ModalityType.APPLICATION_MODAL);
I then overrode the setVisible method:
#Override
public void setVisible(boolean b) {
if (b) {
new Thread(new Runnable() {
#Override
public void run() {
showProgress();
}
}).start();
} else {
super.setVisible(false);
}
}
In the run(), you can see a call to showProgress(). This simply is:
public void showProgress() {
super.setVisible(true);
}
What happens here, is the setVisible() method of JDialog blocks. So I overrode it, and called setVisible() of the JDialog, in a thread. Resulting in it not blocking.

Java: Can't get wait/notify to work properly - Concurrency issue

It's been a long time since I had to deal with concurrent programming in Java (it was in concurrent programming college classes, actually) and I'm having what to seem some pretty basic problem. The sample code below might seem kinda weird since I'm not using standard JDK for UI controls, but it goes like this:
//class Screen
public class Screen{
private Frame rootContainer;
public Screen(Frame rootContainer){
this.rootContainer = rootContainer;
this.createGui();
}
private void createGui(){
Button btn = new Button("Call");
btn.setBounds(20, 20, 100, 20);
rootContainer.add(btn);
btn.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
ConcurrentDialog cr = createDialog();
cr.start();
//Suposedly only to be called after the Exit button in the dialog is clicked
((Button)e.getSource()).setLabel("Called");
((Button)e.getSource()).repaint();
}
});
}
private ConcurrentDialog createDialog(){
return new ConcurrentDialog(rootContainer, this);
}
}
//Class ConcurrentDialog
public class ConcurrentDialog extends Thread {
private Frame rootContainer;
private Screen screen;
public ConcurrentDialog(Frame rootContainer, Screen screen){
this.rootContainer = rootContainer;
this.screen = screen;
}
public void run(){
createDialog();
synchronized(screen){
try {
screen.wait();
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
}
private void createDialog(){
Dialog dialog = new Dialog(rootContainer, true);
dialog.setBounds(20, 20, 110, 35);
Button btn = new Button("Exit");
btn.setBounds(5, 5, 100, 20);
btn.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
Button source = (Button)e.getSource();
Dialog dialog = (Dialog)source.getParent();
synchronized(screen){
screen.notify();
}
dialog.dispose();
dialog.getOwner().remove(dialog);
dialog = null;
}
});
dialog.add(btn);
dialog.show();
}
}
Before anyone asks, yes, I'm trying to implement a modal dialog (in fact, I should rename ConcurrentDialog to ModalDialog). As I said before, I'm not using swing (just because I CAN'T... Embeded VM's are usually platform-specific when it comes to UI and that's my case) and this particular library doesn't have a native Modal Dialog (meaning no JOptionPane.showMessageDialog love for me) so I'm building one from scratch.
Anyway, here's the problem: It seems that the wait() method is executed much later than ((Button)e.getSource()).setLabel("Called"). A workaround that I found is setting btn as a global attribute with public access and refactor the run() method to this:
public void run(){
createDialog();
synchronized(screen){
try {
screen.wait();
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
screen.getBtn().setLabel("Called");
screen.getBtn().repaint();
}
It works this way, but in my "real world" scenario, this implementation would cause quite a mess when it comes to coupling. Any pointers?

your cr.start() returns immediately.
What you want is to put the wait(screen) instead of after cr.start(), and remove wait(screen) from run() method.
This way the thread will show a dialog and exit. Once the dialog is closed, screen will be notified, and your createGui().actionPerformed() will wake up.

you can't use multiple threads with swing/awt, and you can't "wait" on the thread which is running the gui, or it will stop working. the way to do asynchronous work which involves the gui is to spawn a separate thread (as you are doing), and then have that thread use SwingUtilities.invokeLater() whenever it needs to "update" the gui.

Disabling the close x in a JOptionPane

I would like to disable the close x in the upper left corner of my JOptionPane how would I do this?

Michael,
I don't know how to disable the Close[x] button. Alternatively, you can do nothing when user clicks on it. Check the code below:
JOptionPane pane = new JOptionPane("message");
JDialog dialog = pane.createDialog(null, "Title");
dialog.setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE);
dialog.setVisible(true);
Is it reasonable for you?

you can overwrite your exit button by a cancel button declared in JOptionPane and handle your cancellation operation accordingly:
JOptionPane optionPane= new JOptionPane("message", JOptionPane.OK_CANCEL_OPTION);
final JDialog dialog = optionPane.createDialog(null, "Input");
dialog.setDefaultCloseOperation(JDialog.DO_NOTHING_ON_CLOSE);
dialog.addWindowListener(new WindowAdapter() {
#Override public void windowClosing(WindowEvent e) {
optionPane.setValue(JOptionPane.CANCEL_OPTION);
}
});
if (JOptionPane.CANCEL_OPTION!= ((Integer) optionPane.getValue()).intValue())
throw new myCancellationException();

You could always just show the dialog again when the user tries to close it without selecting an option. There's an example of how to override the default closing behavior at sun.com. Look under "Stopping Automatic Dialog Closing" and they have the following code:
final JOptionPane optionPane = new JOptionPane(
"The only way to close this dialog is by\n"
+ "pressing one of the following buttons.\n"
+ "Do you understand?",
JOptionPane.QUESTION_MESSAGE,
JOptionPane.YES_NO_OPTION);
final JDialog dialog = new JDialog(frame,
"Click a button",
true);
dialog.setContentPane(optionPane);
dialog.setDefaultCloseOperation(
JDialog.DO_NOTHING_ON_CLOSE);
dialog.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent we) {
setLabel("Thwarted user attempt to close window.");
}
});
optionPane.addPropertyChangeListener(
new PropertyChangeListener() {
public void propertyChange(PropertyChangeEvent e) {
String prop = e.getPropertyName();
if (dialog.isVisible()
&& (e.getSource() == optionPane)
&& (prop.equals(JOptionPane.VALUE_PROPERTY))) {
//If you were going to check something
//before closing the window, you'd do
//it here.
dialog.setVisible(false);
}
}
});
dialog.pack();
dialog.setVisible(true);
int value = ((Integer)optionPane.getValue()).intValue();
if (value == JOptionPane.YES_OPTION) {
setLabel("Good.");
} else if (value == JOptionPane.NO_OPTION) {
setLabel("Try using the window decorations "
+ "to close the non-auto-closing dialog. "
+ "You can't!");
}
Using that code, you could easily adapt the commented section to only allow the window to be closed when the user has clicked one of the available options and not the close button.

I'm not sure if there is a way to do this in JOptionPane.
Usually when people want more flexibility than JOptionPane offers (it's basically a bunch of static factories for a few dialogs), they write their own dialogs using JDialog.
JDialog offers the inherited method setUndecorated, which eliminates the X altogether. It's more work but you can make your dialog look however you want.