Wie mache ich non-modal dialog, dessen setVisible-Methode blockiert?

In einem Schwung (J)Dialog, setModal legt die Modalität - also ob der dialog sollte-block-Eingang, um andere Fenster oder nicht. Dann, setVisible-Methode docs sagen für modale Dialoge:

Wenn das Dialogfeld nicht angezeigt wird, wird dieser Anruf wird nicht zurückkehren, bis der dialog ausgeblendet wird durch Aufruf der setVisible-Methode(false) oder dispose auf.

Tatsächlich setVisible hat Rückkehr sofort, wenn der dialog nicht modal ist. Beispiel-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");

Möchte ich einen dialog, der nicht block input zu den anderen Fenstern, aber immer noch hat den Anrufer blockieren. Was ist ein guter Weg, dies zu tun, jetzt, dass setVisible nicht blockiert, wenn der dialog nicht modal ist?

Gibt es einige Gründe warum setVisible's Verhalten ist abhängig von der Modalität?

Lesen Sie die obige Zeile in die Google docs: es ist ziemlich deutlich sagt: "Notizen für modale Dialoge."
Oops, mein schlechtes. - Bearbeitung...

InformationsquelleAutor Joonas Pulakka | 2011-08-01

5

Ich brauche, um einen dialog, der nicht blockiert die Eingabe in andere Fenster, aber nicht den Anrufer blockieren, so dass ich weiß, wenn der dialog geschlossen wurde.

Ich in der Regel lösen diese nicht durch die Blockierung der Anrufer, aber durch die Verwendung einer callback-irgendeiner Art - eine einfache Schnittstelle, die den dialog aufruft, wenn es fertig ist. Lassen Sie uns sagen, dass Ihr dialog einen "OK" und "Abbrechen" - Schaltfläche und Sie brauchen, um zu unterscheiden, welche ein gedrückt wird. Dann könnte man etwas wie das hier tun:
```
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();
    }
}
```
Dann haben Sie gerade den pass in einer Instanz von DialogCallback an den Konstruktor:
```
MyModelessDialog dlg = new MyModelessDialog(new DialogCallback() {
    public void onOK() { 
        //react to OK
    }
    public void onCancel() { 
        //react to Cancel
    }
 });
```
BEARBEITEN

Gibt es einige Gründe, warum die setVisible-Methode das Verhalten hängt von der Modalität?

Gut, genau so wie modal Fenster sollen arbeiten, nicht? Ein modales Fenster sollte block den aktuellen workflow, wenn Sie angezeigt werden, und eine nicht-modale/nicht-modale sollte nicht. Siehe z.B. die Wikipedia-Seiten auf modale Fenster oder Dialogfelder.
- Danke, Rückruf scheint gut zu sein Lösung.
- Darüber, wie modal windows arbeiten sollten: zum Beispiel java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/... Gespräche nur über Blockierung Eingang zu einigen anderen top-level-Fenster in der Anwendung. Es sagt nichts darüber aus, warum die caller ist blockiert modale, nicht aber in nicht-modale Fällen. Blockieren user-Eingabe für windows und blockieren Programm-Aufrufe von Methoden sind zwei völlig verschiedene Dinge, IMO. Es gibt wohl einige gute Gründe, warum Sie können nicht unabhängig voneinander eingestellt, aber ich habe noch, es zu verstehen.
- Naja, AFAIK "application modale" Dialoge (das ist die Standard-Modalität type in AWT) anhalten des Programmablaufs und blockieren Ihre Anrufer, wenn Sie angerufen werden. Und das ist, wie Sie funktionieren sollte, meines Wissens. Ich weiß nicht, warum das Java-Artikel, die Sie verknüpft, ist nicht klar, in diesem Punkt, aber die Dokumentation zum Dialog.setVisible-Methode() ist definitiv.
- Die Dokumentation ist klar, und vielleicht ist mein Verständnis von Modalität / nicht-Modalität ist falsch. Aber als Sie Ihren Rückruf "workaround" - Lösung zeigt, gibt es Anwendungsfälle, bei denen es nützlich wäre, einen dialog zu blockieren, die caller ohne die Blockierung der Eingabe.
- Dies funktioniert nicht für mich. Ich erstellte Schnittstelle in einer eigenen Datei. Ich fügte hinzu, Tasten öffentlichen MyModelessDialog(DialogCallback aber ich bekomme callbacException in thread "main" java.lang.IllegalArgumentException: adding a window to a containerk) . Würden Sie buchen ein komplettes Beispiel, bitte?
- Quick-and-dirty proof-of-concept: pastebin.com/EEmbMbYM
InformationsquelleAutor perp
0

Setzen Sie einfach this.setModal(true) aber nicht legen Sie den übergeordneten dialog auf der Konstruktor:

MyDialog dlg = new JDialog();

this.setModal(true);

Beim Aufruf setVisible(true) es wird nicht aufhören,

InformationsquelleAutor Noman_1
0

Dem direkten Ansatz ist:
```
JDialog dialog = new JDialog(owner, ModalityType.DOCUMENT_MODAL);
```
- Erklären, warum das funktioniert.... Ich verstehen auch nicht die Notwendigkeit für eine Antwort, wenn eine ausführlichere (und akzeptiert) Antwort ist bereits verfügbar.
InformationsquelleAutor Karthi
0

Ich habe einen anderen Weg gefunden, dies zu tun. In dem Konstruktor meiner progress-bar, die sich javax.swing.JDialog, fügte ich hinzu:
```
setModalityType(ModalityType.APPLICATION_MODAL);
```
Ich dann überschrieb die setVisible-Methode Methode:
```
@Override
public void setVisible(boolean b) {
    if (b) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                showProgress();
            }
        }).start();
    } else {
        super.setVisible(false);
    }
}
```
In der run () können Sie sehen, einen Anruf zu showProgress(). Das ist ganz einfach:
```
public void showProgress() {
    super.setVisible(true);
}
```
Was hier passiert, ist die setVisible-Methode () - Methode JDialog blockt. Also ich überschrieb es und rief setVisible-Methode() des JDialog, in einem thread. Wodurch es nicht zu blockieren.
- Dies kann funktionieren, aber das aufrufen setVisible() von anderen als dem event-dispatch-thread ist nicht sicher.
InformationsquelleAutor JC Wouters

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.