D:\inferno>java -version
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

Calling printDialog() or pageDialog() on a java.awt.print.PrinterJob yields
dialogs which when dragged do not trigger redraws of obscured Swing components
of that application. This looks terrible. Additionally these dialogs should
behave like normal modal dialogs but do not, i.e., they fall behind the
application's window and don't block interactions with the application's frame.

This testcase demonstrates the problem. In this example the main window is
small, but keep in mind that in reality it would be a full application.
Run the testcase and click on either the Print or Page Setup buttons and note
the following bugs.
Note that when either dialog comes up the main window no longer redraws as it
should.
Further note that the dialogs' modalities are strange--neither modal nor
modaless. For example, the dialog is allowed to fall behind the main window and
you can click on the main window's Minimize, Maximize and Close buttons.
The correct behavior of Print and Page Setup dialogs (and of modal dialogs in
general) is demonstrated in any Windows application, e.g., Notepad.exe. Note
that in these applications modal dialogs are completely blocking but allow the
application to continue to redraw its UI.

/*
 * A testcase to demonstrate redraw problems caused by PrinterJob dialogs.
 */
package buggy;

import java.awt.*;
import java.awt.print.*;
import java.awt.event.*;
import javax.swing.*;

public class Testcase extends JPanel {
  static JFrame m_frame;

  public Testcase() {
    JButton printBtn = new JButton("Print...");
    JButton pageBtn = new JButton("Page Setup...");

    printBtn.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent event) {
        PrinterJob job = PrinterJob.getPrinterJob();
        job.printDialog();
      }
    });

    pageBtn.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent event) {
        PrinterJob job = PrinterJob.getPrinterJob();
        job.pageDialog(job.defaultPage());
      }
    });

    add(printBtn, BorderLayout.CENTER);
    add(pageBtn, BorderLayout.CENTER);
  }

  public static void main(String str[]) {
    Testcase panel = new Testcase();
    m_frame = new JFrame("Testcase");
    m_frame.addWindowListener(new WindowAdapter() {
      public void windowClosing(WindowEvent e) {
        System.exit(0);}
      });
    m_frame.getContentPane().add("Center", panel);
    m_frame.setLocation(200, 200);
    panel.setPreferredSize(new Dimension(200, 200));
    m_frame.pack();
    m_frame.setVisible(true);
  }
}
(Review ID: 132605) 
======================================================================

N/A

If this is still reproducible in Tiger, we should fix it for that release.  
  xxxxx@xxxxx   2001-09-26





PageSetup dialog is a native modal dialog. When it's displayed on EventDispatchThread
it blocks the event pump. java.awt.Dialog solves this problem by starting new event
pump. PrintDialog was fixed so that it is shown as if java.awt.Dialog is shown
(really the native dialog is shown on another thread and new event pump is started
on EventDispatchThread).
So it's better to fix PageDialog in the same way.

====================================================================== 

I'll commit this to Tiger based on developer demand for the fix.  
  xxxxx@xxxxx   2003-09-26

The problem occures under Windows platform 1.3.1 but not under Linux. I also realised that the call to 
pageDialog(pageFormat) take queit some time until it returns.

We also encountered this abnormal behavior. It would be 
kind if it would be corrected for the 1.4 RC. We tried the
1.4 beta 2 and it is not yet fixed in it.

Using MS Spy shows that:

1.  Swing window and Windows standard "Page Setup" dialog 
are served by the same thhread, so no wonder Swing window 
cannot be repainted.

2.  Page Setup dialog is missing a parent window.

There is a workaround for printDialog() which is to launch it 
from a separate Thread so the main thread is not suspended. 
The same workaround won't work that nicely with pageDialog 
because does not put the system in modal mode and 
therefore if you launch this dialog from a separate thread, 
you will be able to click in the parent window. You can try 
disable the parent before calling pageDialog but in my case, 
the parent is minimized.

This is still happening in 1.4.2-b28.

This ugly and non-professional looking bug is STILL HAPPENING in 1.4.2_06-b03. Yet another case of a bug being marked fixed that is NOT FIXED.