-
Bug
-
Resolution: Fixed
-
P2
-
6u12
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2192223 | 7 | Unassigned | P5 | Closed | Cannot Reproduce |
Since the 6637655 (Mixing of heavyweight/lightweight components does not wrk with GlassPane childre) has been fixed, the hw/lw mixing now takes into account non-opaque containers that contain opaque children when traversing the component hierarchy upwards to calculate the current shape (see Component.calculateCurrentShape()).
However some cases still do not work. Consider there's an opaque lightweight component that shows up in a non-opaque container. Currently the mixOnShowing() method will take the parent of the showing component (i.e. its non-opaque container) and invoke the recursiveSubtractAndApply() method for that container. Actually, after this operation is complete, the method must also get the parent of the container and do the same operation for all of the components that are placed below the container in the z-order. Otherwise the shown component may not affect the shape of heavyweight components in other containers. The following test demosntrates the bug:
import javax.swing.*;
import java.awt.*;
public class MyTest {
private static void createGui() {
final JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setLayout(null);
final Button button = new Button("AWT Button");
button.setBounds(100,100,100,100);
frame.add(button);
frame.getGlassPane().setVisible(true);
Container glassPane = (Container) frame.getGlassPane();
glassPane.setLayout(null);
final JButton jbutton = new JButton("JButton");
jbutton.setBounds(50,50,100,100);
glassPane.add(jbutton);
(new Thread(){
public void run(){
try{
Thread.sleep(3000);
jbutton.setVisible(true);
Thread.sleep(3000);
jbutton.setBounds(50,50,110,110);
}catch(Exception e){}
}
}).start();
jbutton.setVisible(false);
frame.setSize(400, 400);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
public static void main(String[] args) throws Exception {
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
MyTest.createGui();
}
});
}
}
Actually the shape of the lightweight button in the GlassPane must be cut off of the heavyweight AWT button, but in the current implementation it does not. This is a bug.
However some cases still do not work. Consider there's an opaque lightweight component that shows up in a non-opaque container. Currently the mixOnShowing() method will take the parent of the showing component (i.e. its non-opaque container) and invoke the recursiveSubtractAndApply() method for that container. Actually, after this operation is complete, the method must also get the parent of the container and do the same operation for all of the components that are placed below the container in the z-order. Otherwise the shown component may not affect the shape of heavyweight components in other containers. The following test demosntrates the bug:
import javax.swing.*;
import java.awt.*;
public class MyTest {
private static void createGui() {
final JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setLayout(null);
final Button button = new Button("AWT Button");
button.setBounds(100,100,100,100);
frame.add(button);
frame.getGlassPane().setVisible(true);
Container glassPane = (Container) frame.getGlassPane();
glassPane.setLayout(null);
final JButton jbutton = new JButton("JButton");
jbutton.setBounds(50,50,100,100);
glassPane.add(jbutton);
(new Thread(){
public void run(){
try{
Thread.sleep(3000);
jbutton.setVisible(true);
Thread.sleep(3000);
jbutton.setBounds(50,50,110,110);
}catch(Exception e){}
}
}).start();
jbutton.setVisible(false);
frame.setSize(400, 400);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
public static void main(String[] args) throws Exception {
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
MyTest.createGui();
}
});
}
}
Actually the shape of the lightweight button in the GlassPane must be cut off of the heavyweight AWT button, but in the current implementation it does not. This is a bug.
- backported by
-
JDK-2192223 Recursive procedures in the HW/LW Mixing code must traverse parent containers
- Closed
- duplicates
-
JDK-6785497 PIT : List is not rendered correctly if JScrollPane scrollbar is moved
- Closed
- relates to
-
JDK-6637655 Mixing of heavyweight/lightweight components does not wrk with GlassPane childre
- Resolved