🚀 go-pugleaf

Admittedly, I am a novice at this (but a C++ and VB programmer for about 20
years), so  I may be doing something wrong, but I just tried it and the
JOptionPane was definitely modal to the the Frame:

here's the code I wrote:


public class Frame1 extends JFrame implements WindowConstants {
  //Construct the frame
  public Frame1() {
    super ("Focus Frame");
    setSize(400,400);
//...code where a series of JInternalFrames are created is omitted....

 WindowAdapter a = new WindowAdapter() {
      public void windowClosing(WindowEvent e) {
        int confirm = JOptionPane.showOptionDialog(null, "Really exit?",
            "Exit Confirmation",
            JOptionPane.YES_NO_OPTION,
            JOptionPane.QUESTION_MESSAGE,
            null, null, null);
        if (confirm == 0) {
          //Frame1.dispose();
          System.exit(0);
        }
      }
    };

  addWindowListener(a);
 }
  public static void main (String[] args) {
    Frame1 frame = new Frame1();
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setBounds(0,0,600,450);
    frame.setVisible(true);
  }

When I run this, and try to exit (via the Java cup icon in the top left) the
exit dialog is definitely modal.

RON

"Tor Iver Wilhelmsen (TeamB)" <tor.wilhelmsen@ergo.no> wrote in message
news:u8yi632td.fsf@ergo.no...
> "Ron" <rgans@nospamRonaldgansphotographyDOTcom> writes:
>
> > Thanks! I tried it and it worked, but then the question: I used null and
> > that worked also. Both Frame1.this and null seem to have the same
> > functionality, in this very tiny example.
>
> It does - until you bring the frame to the foreground. If you have
> passed the frame to JOptionPane, the modal dialog will then pop to the
> foreground; otherwise the modal dialog remains in the background and
> the user will not know why they can\t interact with the frame.