Using the code given below, bring up the internal
message dialog. Click on the JTextField & focus is
moved there. Worse if you bring up the 
JOptionPane.showMessageDialog() before dismissing
the internal dialog you are totally locked up.

import java.awt.*;
import java.awt.event.*;
import com.sun.java.swing.*;

class TestFrame extends JFrame {
  TestFrame()  {
    getContentPane().setLayout(new FlowLayout());

    JButton dlgErrBtn = new JButton("Dialog error msg");
    dlgErrBtn.addActionListener(new DlgErrBtnController());
    getContentPane().add(dlgErrBtn);

    getContentPane().add(new JTextField("hello world")); 

    JButton dlgInErrBtn = new JButton("Internal Dialog error msg");
    dlgInErrBtn.addActionListener(new DlgInErrBtnController());
    getContentPane().add(dlgInErrBtn);
    
    addWindowListener(new WindowAdapter() {
      public void windowClosing(WindowEvent e) {
        System.exit(0);                                                
      }                                       
    });                 
    
    Msg.setParent(this);
  }

  class DlgErrBtnController extends AbstractAction {
    public void actionPerformed(ActionEvent evt) {
      Msg.err("Hello World\nWe have bugs\n");
    }
  }

  class DlgInErrBtnController extends AbstractAction {
    public void actionPerformed(ActionEvent evt) {
      Msg.errIn("Hello World\nWe have bugs\n");
    }
  }
}                 

class Msg {     
  public static void err(String s) {
    if (frame == null)
      System.out.println(s);
    else
      JOptionPane.showMessageDialog(frame.getContentPane(),s,"Standard Dialog",JOptionPane.INFORMATION_MESSAGE);
  }
  public static void errIn(String s) {
    if (frame == null)
      System.out.println(s);
    else
      JOptionPane.showInternalMessageDialog(frame.getContentPane(),s,"Internal Message Dialog",JOptionPane.INFORMATION_MESSAGE);
  }
  
  public static void setParent(JFrame f) {
    frame = f;
  }
  private static JFrame frame;
}

public class TestApp {
  TestApp() throws Exception {
    UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
    frame = new TestFrame();
    frame.setSize(400,300);
    frame.setVisible(true);
  }

  public static void main(String[] argv) {
    try {
       new TestApp();
    }
    catch(Exception e) {
      System.out.println(e);
      e.printStackTrace();
    }
  }

  TestFrame frame;
}
(Review ID: 30613)
======================================================================

N/A

In the current Swing release, there are exceptions generated when 
running this test case.  (And yet the test case continues to run, and
demonstrate the described bug.)  I would guess that the exceptions
that are occuring point to the basic cause of the problem. 

 xxxxx@xxxxx  1998-05-27

Running with 1.3 I'm not seeing anything lock up, but indeed the internal
message dialog is not modal.

To implement the jinternalframe modality properly, we'd really need modal 
support from the JDesktopPane/JInternalFrame infrastructure.  Maybe we'd
even like to add a JInternalDialog subclass which supported the modality
to keep the api orthagonal to the JFrame/JDialog api. ??



 xxxxx@xxxxx  2000-02-16
 xxxxx@xxxxx  2000-02-16
--------------------------------------------------------------------------------
You may close out this bug as fixed and integrated because I ran the demo
program in the X-description and it ran OK with the Kestrel courtesy
release and Tweety.  It threw lots of exception in jdk1.2 but that's
no longer the case.

Roger Pham 4/17/2000

This is still an issue in 1.4.  Looking into what's required to implement
this.
 xxxxx@xxxxx  2002-02-08

I have the same problem. Displaying a dialog with
JOptionPane.createInternalMessageDialog( ... )
creates a non-modal dialog. Trying to drag the dialog
causes a null pointer exception.
This bug makes it impossible to create modal dialogs
in JApplets.
Any idea or workaround???

This bug is around for more than a year. 
I would really appreciate a statement from javasoft concerning a workaround or
solution..

				beepIt = false;
				// fall through
			      case MouseEvent.MOUSE_RELEASED:
				// Mouse clicks are suspicious, check whether
				// the click is inside this JInternalFrame
				Point p = SwingUtilities.convertPoint(srcComponent,
((MouseEvent)event).getPoint(), this);
				if (this.contains(p))
				  dispatchIt = true;
				break;
			      default:
				dispatchIt = true;
			      }
			  }
			if (dispatchIt)
                          ((Component) src).dispatchEvent(event);
			else
			  {
			    if (beepIt)
			      // Otherwise drop event and beep
			      Toolkit.getDefaultToolkit().beep();
			  }
                      } else if (src instanceof MenuComponent) {
                          ((MenuComponent) src).dispatchEvent(event);
                      } else {
                          System.err.println("unable to dispatch event:
" + event);
                      }
                }
            } else
                while (isVisible())
                    wait();
        } catch(InterruptedException e){}
    }

  /**
   * Find the topmost container
   * hth
   */
  private Container getTopContainer (Component c)
  {
    Container parent;
    while ((parent = c.getParent()) != null)
      c = parent;
    if (c instanceof Container)
      return (Container) c;
    else
      return null;
  }
I must admit that this is not a perfect fix, 
I have seen that dismissing some dialogs using
the keyboard with the mouse outside does not
work properly, the OK button gets some attention
but it does not dismiss the dialog.
It works a lot better than the original code, at
least for me.  Use it at your own risk.
The downside of this is that you have to take
Swing apary for every release Sun does.
I had no choice as the window based JOptionPanes
are totally useless as they randomly deadlock in
our environment.

Modal internal JOptionPanes has never been modal
due to JInternalFrame.startModal() which is more
or less just a dummy.  It starts its own event
dispatcher, but it does no filtering.  Worse, in
1.1.1 beta 2, Sun added a new bug which causes a
NullPointerException (should be named
NullReferenceException, right?) when the internal
dialog is dismissed.  Another annoying thing is
the backtrace which has the important line number
truncated!  Boy was I angry when I found that out...
I have not seen the drag NullPointerException
as mentioned in another comment though.
I got fed up with this and hacked Swing to
get it to work.  This is not a perfect fix, but
it works reasonably well for me.
To solve the NullPointerException, change 
BasicInternalFrameUI around line 370 to:
	/// Handle the action events from the Frame
	} else if(JInternalFrame.IS_CLOSED_PROPERTY.equals(prop)) {
	    if(newValue == Boolean.TRUE){
	      // Added frame.getDesktopPane() below -- hth
	      if (frame.getDesktopPane() != null && componentListenerAdded)
	        frame.getDesktopPane().removeComponentListener(componentListener);
The missing null reference I added above exists 
in a very similar code section elsewhere in the 
same class.
To fix the non-modal internal frames, change
JInternalFrame.startModal() to:

    /*
     * Creates a new EventDispatchThread to dispatch events from. This
     * method returns when stopModal is invoked.
     */
    synchronized void startModal() {
	/* Since all input will be blocked until this dialog is dismissed,
	 * make sure its parent containers are visible first (this component
	 * is tested below).  This is necessary for JApplets, because
	 * because an applet normally isn't made visible until after its
	 * start() method returns -- if this method is called from start(),
	 * the applet will appear to hang while an invisible modal frame
	 * waits for input.
	 */
	if (isVisible() && !isShowing()) {
	    Container parent = this.getParent();
	    while (parent != null) {
		if (parent.isVisible() == false) {
		    parent.setVisible(true);
		}
		parent = parent.getParent();
	    }
	}
	Container topRoot = getTopContainer(this);
        try {
            if (SwingUtilities.isEventDispatchThread()) {
                EventQueue theQueue = getToolkit().getSystemEventQueue();
                while (isVisible()) {
                    // This is essentially the body of EventDispatchThread
                    AWTEvent event = theQueue.getNextEvent();
                    Object src = event.getSource();
                    // can't call theQueue.dispatchEvent, so I pasted it's body
here
                    /*if (event instanceof ActiveEvent) {
                      ((ActiveEvent) event).dispatch();
                      } else */ if (src instanceof Component) {
			boolean dispatchIt = false;
			boolean beepIt = true;
			Component srcComponent = (Component) src;
			Component srcRoot = getTopContainer(srcComponent);
			if (srcRoot != topRoot)
			  // Not in the same hierarchy, dispatch it
			  dispatchIt = true;
			else 
			  {
			    switch (event.getID())
			      {
			      case KeyEvent.KEY_RELEASED:

We really do need modal internalframe dialogs.  I've tried a few recommended
approaches (involving the glasspane, event queue, etc.), but settled on this
one.  It is also not perfect.  Below is a cut & paste (oh noooo!) from an
EMail to swing@eos.dk I posted.  This hack enforces a reasonable degree of
modality without digging too deep into swing code.  This is a first draft of
the code:

I can pass along some info about modal dialogs within the 1.2.2 plug-in.  I
assume you've looked at the API and tried the JOptionPane.showXXXXXDialogs and
found they do not result in modal dialogs as the API states.  Searching the JDC
& newsgroups you find modal dialogs with Swing a hot topic.  I was able to
get mostly modal dialogs going internalframe/lightweights) by extending bits
found in the jdc & NG posts.  Initially, this approach blocks UI to the
desktop, blocking menu+toolbar UI is tbd. If anyone has a better solution,
we're listening.

We needed internalframe modal dialogs showInternalXXXX) to avoid screen
flashing on some machines when using heavyweight dialogs (showXXXX).  The
approach uses a JPanel added to the JLayeredPane.PALETTE_LAYER layer (between
the presentation layer & modal layer) that when set to visible tosses any
UI other than that of higher-layer windows (eg. modal layer ones).  The modal
blocking JPanel is static, transparent, has a wait cursor and is dynamically
added to the desktop when modality is required.  Code snippets:

Single instance blocking JPanel in main class (JReview):

modalBlocker = new JPanel(); 
modalBlocker.setOpaque(false);  // An empty, clear JPanel with a WAIT_CURSOR...
modalBlocker.setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR));
modalBlocker.addMouseListener(new MouseAdapter() {});
modalBlocker.addMouseMotionListener(new MouseMotionAdapter() {});
// By adding this to the PALETTE_LAYER, it is BETWEEN the DEFAULT MDI layer and
the MODAL layer,
// it can steal GUI activity from the regular JIFs, but not the one in the
MODAL layer.
// Add to desktop pane had to be dynamic due to frame minimize problems when
statically added....
// Moved to MyDesktopPane... MainPane.add(modalBlocker,
JLayeredPane.PALETTE_LAYER);
modalBlocker.setVisible(false);  // Setting it visible enables GUI blocking....

A subclass of JDesktopPane:

public class MyJDesktopPane extends JDesktopPane {

private static boolean allowModals = true;
private static JInternalFrame thisJIF = null;
private static blockListener thisJIFblock = null;

public void add(Component comp, Object constraints) {  // Intercept
showInternalXXX adds to desktop....
    if ((comp instanceof JInternalFrame) && (constraints instanceof
Integer)) {
        if (((Integer)constraints).intValue() ==
JLayeredPane.MODAL_LAYER.intValue()) {
            if (!allowModals) {  // class boolean set to allow/disallow modal
adds...
                //System.out.println("allowModals is false!");
                return;  // Avoid more than 1 modal dialog...
            }
            // Must dynamically add modalBlocker to/from active desktoppane to
avoid JIF iconize problem....
            JReview.getActiveDesktop().add(JReview.getModalBlocker(),
JLayeredPane.PALETTE_LAYER);
            // Must reset modalBlocker size to current desktop size..
            JReview.getModalBlocker().setSize(JReview.getMainPane().getSize());
            thisJIF = (JInternalFrame)comp;
            thisJIFblock = new blockListener();
            //System.out.println("Adding modal listener
to:"+thisJIF);
            // Invoking palette layer GUI blocker.  Upon modal JIF show, enable
blocker...
            thisJIF.addInternalFrameListener(thisJIFblock);
        }
    }
    super.add(comp, constraints);
}
    
class blockListener implements InternalFrameListener {
    // overriding internalFrameOpened had NO effect... so override
internalFrameActivated...
    public void internalFrameActivated(InternalFrameEvent e) { 
        JReview.getModa

SUN... you guys have to address this problem.  We cannot 
make true MDI applications without this functionality.  

You know... I love Java but I am sick and tired of this 
stupidity.  This has been a problem since Swing was 
created, it has been known about, and it hasn't been fixed 
for over TWO YEARS.

Its interesting to me... the fact that this bug only has 30 
votes shows me that a sparse few people are using Java for 
serious client-side applications.  Otherwise, this bug 
would be in the top 10.

Take a hint, Sun.  If you want Java to be used on the 
client, you had better fix these bugs.  Nobody takes you 
seriously on the client.

-- Rick

I really need (JOptionPane.showInternalOptionDialog) modal internalframes to make my MDI application look good
and not feel buggy.

Using JOptionPane.showOptionDialog is causing a "bug" in my app.
I am setting up a JOptionPane.showOptionDialog in a TableCellEditor to notify the user about, but anyway I return 
 true(returning false make the focus fall back OK in the editor) in the stopCellEditing() method. The focus is now 
not in the table that was I editing , but in some other component in the gui. The cenario above is working with 
JOptionPane.showInternalOptionDialog but this type is not modal and is therefore useless.
Einar

To get around this problem I place a transparent JPanel 
over the entire window and place the dialog on top of the 
JPanel.  Its lame but it works.

Sun, you could fix this problem with a few dozen lines of 
code.  You could fix the current threading mess with 
JInternalFrame, or use a less complicated interim solution 
such as a dummy component to intercept mouse and key events 
targeted behind the modal dialog (as I have done.)  Please 
do something soon.

we have July 2001 ... and we still need modal internal dialogs! this is really a big problem. please, fix it finally - pleeeeeeeeease!!! :-)

I can't believe that. I am doing swing application for some 
time now and I never used 
JOptionPane.showInternalMessageDialog() before 'cause we 
usally anchored the Dialog to the main frame. But I thought 
using it could be a good idea. Due to the problems I looked 
into the bug database and could hardly believe my eyes.

This bug is over 3 years old now!! Will a fix lead to side 
effects or incompatibilities or why didn't happen anything ?

So I will return to my bad, old style giving a reference to 
the enclosing JFrame to all JInternalFrames for usage in 
their Dialogs ??!

I have implemented a ModalJInternalFrame. It works very 
good and I am using it for all my applications.

If people are interested in this I could publish the source 
on the web. Please e-mail me if you're interested.

JOptionPane.showInternalOptionDialog(...) and the like need
to do one better again.  If the window containing the
JDesktopPane is closed before the dialogue box is dismissed,
the showInternalOptionDialog method never returns.  This
causes some problems where programs should be exiting but
hang instead.

Since there is no Fix Release specified, I am adding a vote
to this bug and filing another for the one I've just mentioned.

I've put my modal JInternalFrame implementation online. You
can find it here:

http://www.pandoramix.org/software.html

Please e-mail me any comments or bugs!

Unfortunate to say, but even if this bug is fixed I wouldn't be 
able to use showInternalMessageDialog because if the 
currently active frome is maximized, the dialog becomes 
maximized.  So I just have to use showMessageDialog which 
seems to work fine.  The desktop manager classes need more 
sophistication to properly support message dialogs in MDI.

4 years and counting - may I take this opportunity to thank 
Sun for their continued responsiveness to the developer 
community.
Perhaps Sun should introduce a list of bugs ranked by their 
age - might raise a few questions at Sun if they did!!!

While I was cleaning up my mailboxes I stumbled upon a Dec 
2001 Tech Tips article with Modal JIF workarounds:

http://developer.java.sun.com/developer/JDCTechTips/2001/tt
1220.html

by John Zukowski that is pretty darn good & seems to cover 
the workaround approaches.
Still, those workarounds are not perfect (eg. 2nd approach 
with eventqueue while-loop can leave IE/plug-in JVM hung if 
user slams IE shut while dialog is up).  An approach similar to 
the 1st one is working better for us.

Sun still needs J2SE platform correction to get the 
showInternalXXXXDialogs working as developers/users expect 
(like their showXXXXDialog cousins).

This modal functionality really needs to be in JInternalFrame, 
or perhaps a subclass.  Please consider adding a setModal() 
method and/or a modal parameter in a constructor of 
JInternalFrame.

An interesting problem would be whether the contents of the 
entire surrounding root pane should be inaccessible when the 
dialog is modal, or just the desktop pane.  What happens if 
there are two or more desktop panes in the one frame?  I 
don't know of anyone crazy enough to do this, but it is 
possible.  A setModalType method with 
MODAL_TYPE_DESKTOP_PANE and MODAL_TYPE_ROOT_PANE 
enumeration values or something could do the trick in these 
rare cases.

As you now have "fixed" it, could we please have a 
description of the fix? Will it be JInternalDialog or is it "works 
now, no code changes"?

I got notification of this bug being fixed, but no description 
of the fix.  Is this in release 1.4.2?

why do yhey say that this is a closed bug??? i use 1.4.2 and
still can't get modal internal dialogs. it is still
impossible to work with this and i can't even vote for it.

i gave up using JInternalFrames and showInternalDialog()
just because of this.

Why is this bug closed?  Is this fixed in 1.5?

The bug is still there ?
Could Sun provide a fix date ?
Tks
Tullio

It's fixed in tiger-beta.  Try it out!

I guess, it is not solved. I am using 1.5.0_06 with Netbean 5.0 and the JinternalFrame works not as modal dialog.

/*
 *
 * Created on 21. März 2006, 09:46
 */

import java.applet.AppletContext;

import java.applet.*;
import javax.swing.*;

...

import java.util.*;

/**
 *
 */

public class javaPCDB extends JApplet implements Runnable {
...

    private void initComponents() {
        ...
        waiFrame = new javax.swing.JInternalFrame();
        getContentPane().setLayout(new org.netbeans.lib.awtextra.AbsoluteLayout());

        setBackground(new java.awt.Color(0, 0, 0));
        setFont(new java.awt.Font("Tahoma", 0, 11));
        setName("mainAppl");
        setStub(null);

        mainFrame.getContentPane().setLayout(new org.netbeans.lib.awtextra.AbsoluteLayout());
        ...

        waiFrame.getContentPane().setLayout(new org.netbeans.lib.awtextra.AbsoluteLayout());
        waiFrame.setClosable(true);
        waiFrame.setDefaultCloseOperation(javax.swing.WindowConstants.HIDE_ON_CLOSE);
        waiFrame.setTitle("Wer bin ich?");
        waiFrame.setDoubleBuffered(true);
        waiFrame.setFrameIcon(new javax.swing.ImageIcon(getClass().getResource("/_images/javaPCDB.gif")));
        waiFrame.setMaximumSize(new java.awt.Dimension(250, 180));
        waiFrame.setMinimumSize(new java.awt.Dimension(250, 180));
        waiFrame.setName("waiFRAME");
        waiFrame.setPreferredSize(new java.awt.Dimension(250, 180));
        waiFrame.addComponentListener(new java.awt.event.ComponentAdapter() {
            public void componentMoved(java.awt.event.ComponentEvent evt) {
                waiFrameComponentMoved(evt);
            }
        });

        lbl_1.setText("Zentraler Server");
        waiFrame.getContentPane().add(lbl_1, new org.netbeans.lib.awtextra.AbsoluteConstraints(10, 10, 100, 14));

        fld_1.setEditable(false);
        waiFrame.getContentPane().add(fld_1, new org.netbeans.lib.awtextra.AbsoluteConstraints(106, 8, 130, 16));

        lbl_2.setText("Niederlassungs ID");
        waiFrame.getContentPane().add(lbl_2, new org.netbeans.lib.awtextra.AbsoluteConstraints(10, 30, 100, 14));

        fld_2.setEditable(false);
        waiFrame.getContentPane().add(fld_2, new org.netbeans.lib.awtextra.AbsoluteConstraints(106, 28, 130, 16));

        ..  
        waiFrame.setBounds(260, 120, 250, 180);
        aplFrame.add(waiFrame, javax.swing.JLayeredPane.MODAL_LAYER);
        waiFrame.getAccessibleContext().setAccessibleName("waiFrame");
        mainFrame.getContentPane().add(aplFrame, new org.netbeans.lib.awtextra.AbsoluteConstraints(0, 0, 760, 500));
    ...
    }
    ...

    private void actionPerformed(java.awt.event.MouseEvent evt) {
        String cmd = evt.getComponent().getName();
        try {
            if (_debug) {
                System.out.println("MA__: CMD = " + cmd);
            }

            if (cmd.compareTo("WAI") == 0) {
                setWhoAmI();
                waiFrame.setVisible(true);
                waiFrame.moveToFront();
                waiFrame.setSelected(true);
            }
     ...
     }
     ...

I forgot to write, that I did not found any kind of method like showInternalXXXDialog(). If I try it, the compiler produces an error like:

symbol  : method showInternalDialog()
location: class javax.swing.JInternalFrame
                waiFrame.showInternalDialog();
1 error
BUILD FAILED (total time: 2 seconds)