JDK-5109347 : PrinterJob.printDialog() does not support multi-mon, always displayed on primary
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,7,9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2004-09-30
  • Updated: 2015-10-02
  • Resolved: 2010-12-03
Related Reports
Duplicate :  
JDK-8077319 - PrinterJob.printDialog() does not support multi-mon, always displayed on primary
Relates :  
JDK-5109459 - TableDemo-Print message dialog is displayed in the wrong screen, on multi-mon
Relates :  
JDK-8138749 - Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary
Description
PrintDialog shown using PrinterJob.printDialog(attr set) does not support multi-monitor setup. When this API is invoked, the print dialog is always displayed on the default screen device regardless of where the application is running. 

JTable printing internally uses PrinterJob and hence print dialog always appears on primary screen regardless of where the jtable is shown. This is incorrect. 

When I looked at it more closely, this method uses ServiceDialog class for creating the dialog and that indeed supports passing a GC in which we would like to have the dialog. But printer job always uses the GraphicsConfig of the default screen device. 

This is noticed on all platforms since 1.4, on a multi-monitor setup. I tested this with Solaris9, WinXP. This is well noticed on a solaris system having a multi-screen setup with 2 independent monitors.

I have attached a sample test. Execute the sample test on a multi-mon setup. You would see a frame on each of the monitor. Click the button on the frame displayed in the non-default monitor. I would expect the print dialog to be displayed in the same screen where the frame is located. But it gets displayed on the primary screen.
--------------------------------------------------------------------------------

When there are no print services available, calling PrinterJob.printDialog(attr) shows a message dialog 'No PrintService Found'. This dialog is shown always on the primary monitor and not on the monitor where active window is located. So the GC obtained from the active window must be passed to ServiceDialog.showNoPrintService() method as well.
###@###.### 10/12/04 06:03 GMT
Comments
EVALUATION This will not be fixed in 6 update release.
03-12-2010
SUGGESTED FIX This can be fixed by getting the currently active window and using it's graphics config for creating the print dialog. Something like how it is used in the ServiceUI class for identifying the parent of the print dialog. Window w = KeyboardFocusManager.getCurrentKeyboardFocusManager().getActiveWindow(); if (w != null) { gc = w.getGraphicsConfiguration(); } Use gc's bounds to determine the dialog's location. ###@###.### 2004-09-30
30-09-2004
EVALUATION My initial thinking is that printDialog should have versions that take a frame and dialog parameter. Then AWT should deal with this properly. If/when Java2D has made this change, Swing needs to be modified also to pass in the appropriate parameter. ###@###.### 2004-09-30 ================================= This certainly is a very minor issue, but it already works for the native dialog, so it would be good to make the cross-platform one consistent with that. The "culprit" looks to be the code in RasterPrinterJob.java which constructs the ServiceDialog using the default gc :- final GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment(). getDefaultScreenDevice().getDefaultConfiguration(); and this gc is then used to construct the dialog. Getting the gc from the active window is appropriate since in the implementation of the dialog we are already doing that, so as to specify the active window as the parent (owner). The same should be done for the pageDialog. New methods which take a Frame or Dialog parameter won't address the RFE on the existing method, and hopefully usually won't be necessary if we automatically figure out which is the right owner window. ###@###.### 2004-09-30 ============================ Based on discussions with ###@###.###, I think we should add new, but simple, API. We could overload these methods with another that takes a Component parameter. Then, exactly like JOptionPane.createDialog(), that Component can be used to a) position the new dialog relatively, b) fish out the parent frame/dialog to use as the parent. This will also show the dialog in the right graphics context based on the parent frame/dialog. This is a total of two new methods: 1 each for pageDialog() and printDialog(). ###@###.### 2004-09-30 ================================= Just to clarify this would be 4 new methods because there are 2 pageDialog methods and 2 printDialog methods and I'm not at all convinced they are needed. ###@###.### 2004-09-30 ============================
30-09-2004