-
Bug
-
Resolution: Unresolved
-
P3
-
9, 11, 15, 16
-
Fix Understood
-
x86_64
-
windows_10
ADDITIONAL SYSTEM INFORMATION :
This problem occurs using JDK15 and JDK16rc but not on JDK14 or JDK11 (JDK 13 and 12 untested) , Windows 10 OS. (Bug tested against 1600x900 primary display, 3840x2160 secondary display with 150% display scaling).
A DESCRIPTION OF THE PROBLEM :
If a JOptionPane that is parented by a JFrame is made visible after the JFrame has been moved (e.g. user drag) from the frame's initial visible location on a non high DPI display to a location on an scaled high DPI display the JOptionPane size is not correct and as a consequence the option pane contents are cropped.
REGRESSION : Last worked in version 14
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
On a system with a non HDPI and HDPI display with 150% scaling (e.g notebook with attached HDPI monitor) set the primary monitor as the non HDPI display and run the test code below. After the JFrame appears on the primary monitor drag the JFrame to the the HDPI display and click the open button to display the JOptionPane.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Normal layout of the option pane with no clipping of the contents (as is the case in JDK14 and JDK 11 when these actions are performed)
ACTUAL -
Clipped contents in the open pane
---------- BEGIN SOURCE ----------
public class Main extends JFrame {
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
SwingUtilities.invokeLater(Main::createFrame);
}
public static void createFrame() {
try {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JButton open = new JButton("Open");
open.setPreferredSize(new Dimension(300,200));
open.addActionListener((ae)->Main.openMessage(frame));
frame.getContentPane().add(open);
frame.pack();
frame.setVisible(true);
} catch (Exception ex) {
Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
}
}
static public void openMessage(JFrame parent) {
Box box = new Box(BoxLayout.PAGE_AXIS);
box.add(new JLabel("This is line one"));
box.add(new JLabel("This is line two"));
box.add(new JLabel("This is line three"));
JOptionPane.showConfirmDialog(parent, box, "Title", JOptionPane.OK_CANCEL_OPTION);
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Nothing reliable. JDialogs exhibit similar behavior. In the case of JDialog's attempting to change the GraphicsConfiguration to that of the parent frame (using the appropriate constructor) can lead to circumstances where layout is correct, but not in a way that seems predictable, and in any case that is not an option for JOptionPane based dialogs.
FREQUENCY : always
This problem occurs using JDK15 and JDK16rc but not on JDK14 or JDK11 (JDK 13 and 12 untested) , Windows 10 OS. (Bug tested against 1600x900 primary display, 3840x2160 secondary display with 150% display scaling).
A DESCRIPTION OF THE PROBLEM :
If a JOptionPane that is parented by a JFrame is made visible after the JFrame has been moved (e.g. user drag) from the frame's initial visible location on a non high DPI display to a location on an scaled high DPI display the JOptionPane size is not correct and as a consequence the option pane contents are cropped.
REGRESSION : Last worked in version 14
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
On a system with a non HDPI and HDPI display with 150% scaling (e.g notebook with attached HDPI monitor) set the primary monitor as the non HDPI display and run the test code below. After the JFrame appears on the primary monitor drag the JFrame to the the HDPI display and click the open button to display the JOptionPane.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Normal layout of the option pane with no clipping of the contents (as is the case in JDK14 and JDK 11 when these actions are performed)
ACTUAL -
Clipped contents in the open pane
---------- BEGIN SOURCE ----------
public class Main extends JFrame {
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
SwingUtilities.invokeLater(Main::createFrame);
}
public static void createFrame() {
try {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JButton open = new JButton("Open");
open.setPreferredSize(new Dimension(300,200));
open.addActionListener((ae)->Main.openMessage(frame));
frame.getContentPane().add(open);
frame.pack();
frame.setVisible(true);
} catch (Exception ex) {
Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
}
}
static public void openMessage(JFrame parent) {
Box box = new Box(BoxLayout.PAGE_AXIS);
box.add(new JLabel("This is line one"));
box.add(new JLabel("This is line two"));
box.add(new JLabel("This is line three"));
JOptionPane.showConfirmDialog(parent, box, "Title", JOptionPane.OK_CANCEL_OPTION);
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Nothing reliable. JDialogs exhibit similar behavior. In the case of JDialog's attempting to change the GraphicsConfiguration to that of the parent frame (using the appropriate constructor) can lead to circumstances where layout is correct, but not in a way that seems predictable, and in any case that is not an option for JOptionPane based dialogs.
FREQUENCY : always