When an internal frame is not active, it's glass
pane is set to be visible. When this happens
the mouse events that the glass pane recieves
are caught and send down to the appropriate
component within the internal frame.

DropTargets within the internal frame are not so
lucky as the glass pane prevents them from being
recognised.
(Review ID: 33558)
======================================================================

I am re-assigning this bug to swing. DnD uses the Component.findComponentAt() method to map the platform Drag and Drop events to the appropriate Component/DropTarget pair. It has no knowledge (nor should it) of the types of the Containers/Components involved in the hierarchy.

Seems like the internal frames findComponentAt() method needs fixing?


  xxxxx@xxxxx   1998-06-12

Make the glass pane a drop target and then work
out what should happen to the drop.
======================================================================

Overrode findComponentAt so that it ignores glassPanes.
  xxxxx@xxxxx   1998-10-22

Copy of message sent to submitter:

Hi,

As you many know, this bug, which you submitted, is marked as fixed in 1.2.2 and
1.3beta. The bug is caused by a possibly incorrect behavior in Swing
InternalFrames which automatically shows the InternalFrame's glass pane
when the InternalFrame is disabled. If children of the InternalFrame are
DropTargets, they can no longer receive drop events because the glass pane
obscures these events.

The fix currently in the code is a change to JRootPane.findComponentAt which
discards the glass pane in the Component search algorithm used by DnD.
Unfortunately, we have determined that this fix introduces a few substantial
regressions and we need to remove it from the code.

We may try to fix your bug in a different way in the future, but for now, I
suspect the bug will reappear in 1.3. If you are happy with the fix as it
stands, you can implement it yourself in your application. Create your
own glass pane Component which overrides findComponentAt as follows:

  public Component findComponentAt(int x, int y) {
      return null;
  }
  
You can then set this Component to be the root pane's glass pane using
JRootPane.setGlassPane.


Regards,
David Mendenhall
AWT Team
  xxxxx@xxxxx   1999-08-25

This might possibly be related to the problem I have been having in 1.3b. 
If I have an InternalFrame with a DropTarget on it,  a setVisible(true), which
is necessary in 1.3+, will cause an NPE.
java.lang.NullPointerException
        at java.awt.dnd.DropTarget.addNotify(DropTarget.java:430)
        at java.awt.Component.addNotify(Component.java:3948)
        at java.awt.Container.addNotify(Container.java:1663)
        at javax.swing.JComponent.addNotify(JComponent.java:3896)
        at java.awt.Container.addNotify(Container.java:1670)
        at javax.swing.JComponent.addNotify(JComponent.java:3896)
        at java.awt.Container.addNotify(Container.java:1670)
        at javax.swing.JComponent.addNotify(JComponent.java:3896)
        at java.awt.Container.addNotify(Container.java:1670)
        at javax.swing.JComponent.addNotify(JComponent.java:3896)
        at java.awt.Container.addNotify(Container.java:1670)
        at javax.swing.JComponent.addNotify(JComponent.java:3896)
        at java.awt.Container.addNotify(Container.java:1670)
        at javax.swing.JComponent.addNotify(JComponent.java:3896)
        at javax.swing.JRootPane.addNotify(JRootPane.java:477)
        at java.awt.Container.addNotify(Container.java:1670)
        at javax.swing.JComponent.addNotify(JComponent.java:3896)
        at java.awt.Container.addNotify(Container.java:1670)
        at javax.swing.JComponent.addNotify(JComponent.java:3896)
        at javax.swing.JInternalFrame.show(JInternalFrame.java:1392)
        at java.awt.Component.show(Component.java:922)
        at java.awt.Component.setVisible(Component.java:880)
        at javax.swing.JComponent.setVisible(JComponent.java:1817)

I found that David's fix may not work in the JDK 1.3 beta on Win32.
I had to also make sure my "glass pane" class was forced to become
visible when a JInternalFrame was deactivated.  To work around this, I
wrote this class...


    public class GlassPane extends JPanel {
	public GlassPane(){
		super.setVisible(false);
		setOpaque(false);
	}
	public void setVisible(boolean b) {
	}

	public Component findComponentAt(int x, int y) {
System.err.println("findComponentAt called!"); // doesn't seem to get
called at all...
       		return null;
       	}
    }

....and then use setGlassPane(new GlassPane()) to set it up properly.

I had the problem, too (it occured in 1.3rc1 on win32)
Great, the workaround seems to work! Thanks a lot.
... still the class JInternalFrame seems to be a kind of
a curse in many senses ...

I just wanted to mention that the DropTarget of the 
Glasspane will be ignored completely. I considered this a 
bug but now it's a RFE (#4435403).

I hope this will help the desperate (like me) who start to 
doubt about themself.