-
Enhancement
-
Resolution: Won't Fix
-
P4
-
6
-
x86
-
solaris_10
Bug 6407103 demonstrates an undesirable behavior involving one or more of: pack(), JScrollPane/JViewport, layouts, and possibly JFrame/Window, as shown by the test case below.
The scenario is that some very long message string is returned from some backend processs, and put into a JList cell. The list goes into a JScrollPane and into a JFrame, the JFrame is pack()ed, and the frame is shown.
--- Bug6407103.java ---
import java.awt.*;
import javax.swing.*;
public class Bug6407103 extends JFrame {
public Bug6407103() {
super("Bug6407103");
String longString = "";
for (int i = 0; i < 3600; i++) {
longString += "123456789 ";
}
System.out.println("LONG STRING LENGTH = " + longString.length());
JList list = new JList(new String[] { longString, "Another Line" });
list.setSelectedIndex(0);
getContentPane().add(new JScrollPane(list),
BorderLayout.CENTER);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
pack();
System.out.println("Size: " + getSize());
}
public static void main(String s[]) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new Bug6407103().setVisible(true);
/*
Bug6407103 f = new Bug6407103();
f.pack();
f.setVisible(true);
*/
}
});
}
}
---
The problem is that pack() sees that the JList's perferred size is very large, and sizes the JFrame to fit - over 32,000 pixels wide! There is no reason for the JFrame to be so large, since the JList is inside a JScrollPane. However the JFrame is created so big that the scrollbars don't show up, so the user would really have to work to see the entire JList anyway. The GUI would be much friendlier if the the JFrame was sized no larger than the screen size, with the JScrollPane being used to scroll the large JList.
One or more of the following could help pack() behave better in this situation:
* Make pack() smarter about how large it sizes windows, particularly if they contain scrollpanes and/or may be sized larger than the screen(s) size
* Make JViewport/JScrollPane smarter about how large it asks to be via getPreferredSize() (see my Work Around)
* Make setMaximumSize() work, at least for scrollpanes and/or top-levels
* Some other layout-related change
Note that this bug is easier to reproduce on Unix platforms because Windows XP SP2 prevents JFrames from being resized (manually or programmatically) larger than the screen size. I'm guessing this bug happens on older versions of Windows, however. Also, it IS possible to set a non-resiable JDialog to be larger than the screen size, in which case this situation could come into play on Windows XP SP2.
The scenario is that some very long message string is returned from some backend processs, and put into a JList cell. The list goes into a JScrollPane and into a JFrame, the JFrame is pack()ed, and the frame is shown.
--- Bug6407103.java ---
import java.awt.*;
import javax.swing.*;
public class Bug6407103 extends JFrame {
public Bug6407103() {
super("Bug6407103");
String longString = "";
for (int i = 0; i < 3600; i++) {
longString += "123456789 ";
}
System.out.println("LONG STRING LENGTH = " + longString.length());
JList list = new JList(new String[] { longString, "Another Line" });
list.setSelectedIndex(0);
getContentPane().add(new JScrollPane(list),
BorderLayout.CENTER);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
pack();
System.out.println("Size: " + getSize());
}
public static void main(String s[]) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new Bug6407103().setVisible(true);
/*
Bug6407103 f = new Bug6407103();
f.pack();
f.setVisible(true);
*/
}
});
}
}
---
The problem is that pack() sees that the JList's perferred size is very large, and sizes the JFrame to fit - over 32,000 pixels wide! There is no reason for the JFrame to be so large, since the JList is inside a JScrollPane. However the JFrame is created so big that the scrollbars don't show up, so the user would really have to work to see the entire JList anyway. The GUI would be much friendlier if the the JFrame was sized no larger than the screen size, with the JScrollPane being used to scroll the large JList.
One or more of the following could help pack() behave better in this situation:
* Make pack() smarter about how large it sizes windows, particularly if they contain scrollpanes and/or may be sized larger than the screen(s) size
* Make JViewport/JScrollPane smarter about how large it asks to be via getPreferredSize() (see my Work Around)
* Make setMaximumSize() work, at least for scrollpanes and/or top-levels
* Some other layout-related change
Note that this bug is easier to reproduce on Unix platforms because Windows XP SP2 prevents JFrames from being resized (manually or programmatically) larger than the screen size. I'm guessing this bug happens on older versions of Windows, however. Also, it IS possible to set a non-resiable JDialog to be larger than the screen size, in which case this situation could come into play on Windows XP SP2.
- relates to
-
JDK-6422224 In the MBeans tab the operation result dialog box fails to show an array of CompositeData
-
- Closed
-
-
JDK-6407103 GTK L&F: Painting problems on Solaris with very wide frames and bufferPerWindow
-
- Closed
-