JDK-4607481 : Can't open a non-modal window behind a modal dialog
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1,1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2001-12-14
  • Updated: 2005-12-01
  • Resolved: 2005-05-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b38Fixed
Related Reports
Relates :  
Description
Name: gm110360			Date: 12/13/2001


java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)


 There are many bugs which touch upon this issue (modal dialog and non-modal
 window behavior), but I couldn't find one with this spin:

 I have an application that needs to bring up warnings in response to server-
 generated (i.e. not user-generated) events. If there is a modal dialog up when
 I need to bring the new window, there's no way to bring it up behind the modal
 dialog. show() forces it to the front. Furthermore, the newly created window
 does not handle new events (other bugs related to this) and it may obscure the
 modal dialog entirely.

 Need some way to get this to work. Either:
 1) show() should automatically bring non-modal windows up behing modal dialogs
 (any maybe their parent frames)
 2) have some way to programatically inspect the list of open windows by z-
 poition and bring up a window in something other than the front position.
 
 Note: waiting for the user to dismiss the modal diaog is not an option - the
 new window which comes up is urgent in our applciation and needs to be seen
 immediately so the user can act on it.
 
  To reproduce, run the following app and click "Do it" a modal dialog will come
 up and 5 seconds later a new JFrame will be created and shown. The newly
 created frame obscures the modal dialog and does not accept events.
 
import java.awt.event.*;
import javax.swing.*;

public class TrivialApplication {

	public static void main(String args[]) {
		final JFrame mainFrame = new JFrame("Main");
		JButton doItButton = new JButton("Do it");
		doItButton.addActionListener(new ActionListener() {
			public void actionPerformed(ActionEvent e) {
				doIt(mainFrame);
			}
		});
		mainFrame.getContentPane().add(doItButton);
		mainFrame.pack();
		mainFrame.show();
	}
	
	public static void doIt(JFrame parentFrame) {
		waitAndShowJFrame();
		showModalDialog(parentFrame);
	}
	
	public static void showModalDialog(JFrame parentFrame) {
        JDialog modalDialog = new JDialog(parentFrame, "Modal", true);
        modalDialog.pack();
        modalDialog.setBounds(100, 100, 100, 100);
        modalDialog.show();
	}
	
	public static void waitAndShowJFrame() {
		new Thread() {
			public void run() {
				try {
					sleep(5000);
					JFrame frame = new JFrame("new non-modal frame");
					frame.pack();
					frame.setBounds(50, 50, 200, 200);
					frame.show();
				} catch(InterruptedException ie) {
					System.out.println("unexpected InterruptedException");
				}
			}
		}.start();
	}
}
(Review ID: 137207) 
======================================================================
###@###.### 10/4/04 16:52 GMT

Comments
EVALUATION Marking this CR as RFE. I doubt if the API for inspecting and modifying Z-order is planned in AWT in nearest releases, but this particular issue is addressed by the fix for 4080029 (umbrella bug for AWT modality). After this fix all the frames and non-modal dialogs are shown behind the active modal dialog. If one need to show a message on top of the modal dialog, it should made it as a child of modal dialog. ###@###.### 2005-05-03 11:18:58 GMT
03-05-2005

WORK AROUND Name: gm110360 Date: 12/13/2001 User can click on the task bar to bring up the window that owns the modal dialog, but this is not obvious to the user and also hard if there are many windows for the app. Programatically, could probably keep track of window order via window listener events and force modal dialogs back to the front, but this will cause a circus on the user's screen as windows are forced to the correct positions (there may be multiple nested modal dialogs) ======================================================================
17-09-2004