import javax.swing.*;
import java.awt.event.*;
import java.beans.*;

public class SwingTest extends JFrame{

	public SwingTest(){
		super("test");
		addWindowListener(new ExitHandler());
		setSize(300, 300);

		JDesktopPane dtp=new JDesktopPane();
		setLayeredPane(dtp);

		JInternalFrame if1=new JInternalFrame("f1", true, true, true, true);
		if1.setSize(150, 150);
		try{
			if1.setSelected(false);
		}
		catch(PropertyVetoException pve){
			pve.printStackTrace();
		}
		if1.show();

		JInternalFrame if2=new JInternalFrame("f2", true, true, true, true);
		if2.setSize(150, 150);
		try{
			if2.setSelected(true);
		}
		catch(PropertyVetoException pve){
			pve.printStackTrace();
		}
		if2.show();

		dtp.add(if1, JDesktopPane.DEFAULT_LAYER, 1);
		dtp.add(if2, JDesktopPane.DEFAULT_LAYER, 0);

		show();
	}

	public static void main(String args[]){
		new SwingTest();
	}
}

class ExitHandler extends WindowAdapter implements WindowListener{
	public void windowClosing(WindowEvent we){
		JFrame f=(JFrame)we.getSource();
		System.exit(0);
	}
}//end of source code


//Description
//
//When I try to load two JInternalFrames into a JFrame containing a 
//JDesktopPanel to hold them, both JInternalFrames start up having 
//the focus. The only way to get the focus onto one JInternalFrame 
//only is to iconify and then deiconify the two JInternalFrames. After
//this procedure the two frames behave as expected: clicking one moves 
//the focus and brings the frame to front. However, iconifying or 
//closing the frame that has the focus does still not result in the 
//other frame gaining the focus.
(Review ID: 48791)
======================================================================




We are using the Windows look and feel.  Under SWING 1.0.2 if a 
JInternalFrame (JIF) was closed, the previous JIF would become
the selected JIF.  When we switched to SWING 1.1 (and also in 
1.1.1 beta 1) the behavior changed.

Now when a JIF is closed, focus/selection seems to revert to the
first JIF opened.  For example: 3 JIF's are created and added
to the JDesktopPane of a JFrame.  As each is added, we perform a
moveToFront(), and a setSelected() so that the new JIF's are "on
top" and enabled.  After the third one is opened, the app. will 
look something like this...
 _______________________________________
|_|_______________________________|_|_|_|
|   ________________                    |
|  |________________|                   |
|  |    ____________|_____              |
|  | 1 |__________________|             |
|  |   |    ______________|___          |
|  |   | 2 |__________________|         |
|  |   |   |                  |         |
|  |___|   | 3                |         |
|      |   |                  |         |
|      |___|                  |         |
|          |                  |         |
|          |__________________|         |
|_______________________________________|

Now if we close JIF 3, and I would expect JIF 2 to be selected...
Instead, JIF 1 is brought to the front and selected.

The behavior is not consistent with the MDI Look and Feel that is
supposed to be provided by the WindowsLookAndFeel PLAF.

What's happening here???
(Review ID: 54440)
======================================================================




1. Run SwingSet on Window95.
2. Select Options Motif Look & Feel.
3. Select Internal Frame tab.
4. Press Make button twice.
5. 2 internal frames titled "Internal Frame 1" and 
   "Internal Frame 2" are displayed.
   "Internal Frame 2" is on top of "Internal Frame 1" and 
   "Internal Frame 2" is highlighted.
6. Iconify only "Internal Frame 2".
7. Deconify the icon corresponding to "Internal Frame 2".
8. Restored "Internal Frame 2" is covered by "Internal
   Frame 1".
(Review ID: 93601)
======================================================================




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

Problems occur when adding a JInternalFrame to a JDesktopPane when that desktop
pane has some iconified JInternalFrames. (PROBLEM 2 of 2)

The deiconified frames to be will be placed at the back of the z order (though
in the same layer) and clicking the title bar will not bring them to the front.

Reproducing the bug:  Start the SwingSet demo, click the Internal Frame tab.
Make a minimizable frame, then minimize it.  Make another frame.  Then
deiconify the first frame.  Try to bring this frame to front by clicking it -
you can't.

(Another bug report will be filed for a similar bug where the deiconified
frames are always selected when deiconified.)
(Review ID: 100099)
======================================================================

Currently, we have supplanted the WindowsDesktopManager of the 
WindowsLookAndFeel PLAF with our own.

In the switchFrame() method we changed 
        if (next) {
            nextIndex = currentIndex + 1;
            if (nextIndex == count) {
                nextIndex = 0;
            }
        } else {
            nextIndex = currentIndex - 1;
            if (nextIndex == -1) {
                nextIndex = count - 1;
            }
        }
to 

        if (next) {
            nextIndex = currentIndex; // + 1;
            if (nextIndex == count) {
                nextIndex = 0;
            }
        } else {
            nextIndex = currentIndex - 1;
            if (nextIndex == -1) {
                nextIndex = count - 1;
            }
        }

This causes other problems...like throwing control focus 
out-of-whack.  I need to look at it closer when (if) I get time.
(Review ID: 54440)
======================================================================




None.
(Review ID: 93601)
======================================================================

This report ended up a conglamoration of bug reports, some of which have been fixed, and others duplicated in other reports. I need to go through the individual reports added to this one, and figure out what other bug they refer to, or file a separate bug for them. Please try hard not to collapse unrelated bugs.

  xxxxx@xxxxx   1999-09-16




    The bug is not reproducible after the focus
management enhancements.

  xxxxx@xxxxx  

======================================================================

Hi, I have the same problems as you,
but I finally found the problem is that
  You must firstly call 
dtp.add(if1, JDesktopPane.DEFAULT_LAYER);
and then call
setSelected(true);

I have notices some very strange issues surrounding components added to a
JInternalFrame managed by a JDesktopPane, long with the aforementioned bugs
surrounding iconification. 
Initially, I worked around the problem by adding an InternalFrameListener to my
frames, with frame activation events being linked to a call to bringToFront()
(I think that was the name of the call...) -- this works like a dream, until
you iconify the frame and deiconify it -- suddenly the event handler stops
getting called!
Even more astonishing was the behavior when adding Swing components to the said
InternalFrames -- if a call was made to setContentPane(someJTextArea) ,then the
textarea behaves as expected. If on the other hand, a call to
getContentPane().add(someJtextArea) was made, the JTextArea never recieves the
focus. (You can type into it, sure, but there is no caret to indicate where the
content is going to be inserted. This behavior aslo messes up JComboBoxes,
which seem to rely on checking whether they have the focus when choosing which
component is selected.
As an aside, if i create a new component, say a JPanel, and add JComponents to
it, then call setContentPane(myJPanel), I get identical behavior to the second
case outlined above.

This problem seems to have vanished from JDK1.3, 
but it seems to affect all previous versions of Swing/JDK.

So a simple call to dpt.add(jif); must be replaced with hhaining's suggestion
below 
if you wish to maintain backwards compatibility.

martin.coxall@chase.com

is now enough to do what you want it to do.