JDK-4202651 : JTabbedPane cannot be used as content pane of JFrame?
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.1.6,1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-01-13
  • Updated: 2000-03-15
  • Resolved: 2000-03-15
Related Reports
Duplicate :  
Description

Name: krT82822			Date: 01/12/99


original synopsis:  "JTabbedPane tab repaint problem"

There is a repaint problem with JTabbedPane that is most easily reproducable by setting a JTabbedPane as the content pane of a frame.  To see the
problem, run the following code:

JFrame f = new JFrame();
JTabbedPane tp = new JTabbedPane();
tp.add("Test", new JPanel());
f.setContentPane(tp);
f.setSize(200, 200);
f.show();

When the frame shows, partially cover the tab area with another window and then bring the example frame back to the front.  You should see the
tab painted twice.
(Review ID: 36753)
======================================================================

Comments
WORK AROUND Name: krT82822 Date: 01/12/99 The only workaround I know of is to set the content pane to a JPanel with a BorderLayout and then add the JTabbedPane to the JPanel with the BorderLayout.CENTER directive. ---------------- import java.awt.*; import javax.swing.*; public class Test36753 extends JFrame { public static void main(String[] args) { Test36753 f = new Test36753(); f.setLocation(200, 100); f.setVisible(true); } public Test36753() { super("Testing..."); JTabbedPane tp = new JTabbedPane(); tp.add("Test", new JPanel()); setContentPane(new JPanel()); Container c = getContentPane(); c.setLayout(new BorderLayout()); c.add(tp, BorderLayout.CENTER); pack(); } } ====================================================================== Another workaround is to set the opacity of the JTabbedPane to "true": tabbedpane.setOpaque(true);
11-06-2004

EVALUATION Wow! this is definitely still reproducible in 1.3. The problem is really tied to Swing's double-buffer repaint machinery, which doesn't deal well with the condition where a non-opaque component (one which doesn't paint all it's own bits) is the first component in the hierarchy to paint. It's relying on this first component to clear it's background (and hence the contents of the buffer), however in this bug's case the JTabbedPane's opacity is false and so it does not clear the background before painting itself, which results in the buffer never being cleared - hence garbage gets painted. I think the best solution may be to pull the toplevel Swing classes (JFrame, JDialog, JWindow, JApplet) into the repaint algorithms (currently they don't render into the buffer) so that the background of the buffer will initially always be rendered with the background of the topmost component (frame/dialog/window/applet), which is by definition (at least currently) to be opaque. This is really a duplicate of 4155103. amy.fowler@Eng 2000-03-15
15-03-2000