c:\>java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)


This bug seems related to Bug #4218471 which was supposedly fixed in Kestrel
(v1.3).  The problem occurs when the print dialog is displayed.  If the user
moves the print dialog around the Java application behind does not repaint
(while other application windows do repaint).  This is an inconsistency.

If the option on the desktop to “Show window contents while dragging” is turn
on, then the problem occurs the first time that the movement is done.  If this
option is turned off (thus only showing an outline), then the first move seems
to be fine.  However, subsequent moves cause the same problem.

The following is the complete code that I used to demonstrate this:

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

public class PrintDialogBug extends JFrame implements Printable
{
   private myPanel m_myPanel = null;
   private boolean _printing = false;  //boolean indicating printing

   public class myPanel extends JPanel {
      private Dimension sz;
      private String str = "Print Test: myPanel";
      public myPanel() {
         super();
         setPreferredSize(new Dimension(700, 500));
         sz = new Dimension();
         this.setOpaque(true);
      }
      protected void paintComponent(Graphics g) {
         super.paintComponent(g);
         sz = getSize(sz);
         g.setClip(0, 0, sz.width, sz.height);
         g.setColor((_printing)?Color.white:Color.black);
         g.fillRect(0, 0, sz.width, sz.height);
         g.setColor((_printing)?Color.black:Color.yellow);
         g.drawRect(10, 10, sz.width - 20, sz.height - 20);
         FontMetrics fm = g.getFontMetrics();
         int sw = fm.stringWidth(str);
         int sh = fm.getHeight();
         g.drawString(str,
                      (10 + ((sz.width - 20) / 2) - (sw / 2)),
                      (10 + ((sz.height - 20) / 2) + (sh / 2)));
      }
   }

   public PrintDialogBug(String t) {
      super(t);
      setDefaultCloseOperation(EXIT_ON_CLOSE);
      JMenuBar mb = new JMenuBar();
      JMenu m = new JMenu("File");
      m.add(new AbstractAction("Print...") {
         public void actionPerformed(ActionEvent e) { doPrint(); }
      });
      m.addSeparator();
      m.add(new AbstractAction("Exit") {
         public void actionPerformed(ActionEvent e) { System.exit(0); }
      });
      mb.add(m);
      setJMenuBar(mb);
      m_myPanel = new myPanel();
      getContentPane().add(m_myPanel);
   }

   public void doPrint() {
      PrinterJob pj = PrinterJob.getPrinterJob();
      pj.setPrintable(this);
      if (pj.printDialog()) {
         try {
            pj.print();
         } catch (PrinterException e) {
            e.printStackTrace();
         }
      }
   }

   public int print(Graphics g, PageFormat pf, int idx) {
      //since we are currently sizing to fit on one page, we are only
      //  printing one page.
      if (idx >= 1) {
         _printing = false; //turn off printing
         return NO_SUCH_PAGE;
      }

      _printing = true; //flag to notify paint routines that we are printing

      //get the total width and height of the current panels
      int pWidth = m_myPanel.getWidth();
      int pHeight = m_myPanel.getHeight();

      //calculate the scaling ratio
      double w_perChange = percentChange(pf.getImageableWidth(), pWidth);
      double h_perChange = percentChange(pf.getImageableHeight(), pHeight);
      double perChange = Math.min(w_perChange, h_perChange);

      //translate the printer graphic and set scale to scaling ratio
      g.translate((int)pf.getImageableX(), (int)pf.getImageableY());
      ((Graphics2D)g).scale(perChange, perChange);

      m_myPanel.print(g);

      _printing = false; //notify the paint routines that we are done printing
      return PAGE_EXISTS;
   }

   //simple method which check for zero before dividing
   //
   private double percentChange(double to, double from) {
      if (from == 0) return 1.0;
      return to/from;
   }

   /////////////////////////////////////////////////////////////////////////////
////////
   //   main of demo
   //
   public static void main(String[] args) {
      PrintDialogBug vs = new PrintDialogBug("Print Dialog Bug");
      vs.setLocation(10, 30);
      vs.pack();
      vs.setVisible(true);
   }
}
(Review ID: 113018) 
======================================================================

N/A

Fixed using peer.

 xxxxx@xxxxx  2003-03-19

Has anyone discovered a workaround to this bug? I am part 
of a development team that is about to release an 
application which utilises JDKv1.3 and this problem is 
still persists!

This should be considered a major flaw as many Java based 
applications use this feature.  I would strongly recommend 
this to be fixed.

We are also facing similar problem 
can this be handled

It is still not fixed, even in JDK 1.4b2 !! 
It's incredible !
It's the same as :
http://developer.java.sun.com/developer/bugParade/bugs/45075
85.html

See the workaround at www.barsuk.net/notes/printdialog
(site may be down at times as it's a home PC)
The root of this problem seems too be the printdialog (and 
pagedialog too) which are provided by OS (not Java) 
blocking the current thread, which happens to be the event 
dispatch thread. Blocking that thread effectively prevents 
all repainting (as paint is a response to an event).
The first "solution" is to make all calls to 
printdialog/pagedialog in a separate worker thread. That 
does solve the problem with pagedialog, but not with 
printdialog. The printdialog apparently still blocks the 
event thread somehow.
The real solution is to start off a new event pump in a 
worker thread, while blocking the event dispatch thread 
yourself.
Fortunately, this doesn't lead to a deadlock with 
printdialog.
I realize it's a dangerous and hack-like technique, but why 
not (if it works)?

This bug still exists in JDK1.4.1-b21, even though the list of 
fixed bugs for v1.4 includes this item:

Bug ID : 4273333
RFE: Let PrinterJob.printDialog dialog box be optionally modal
State:  Closed, fixed
 


Note the ORIGINAL bug was reported in Sept 1999. As  I type 
this today, 3 full years have passed, and this bug remains. 
Not only that, but you have marked at as FIXED, and included 
it   here:

http://java.sun.com/j2se/1.4/fixedbugs/fixedbugs-all.html

But it's not fixed yet.

Still broken in JDK 1.4.1_01. Tested under Win2000 and WinXP 
and the problem still persists. Come on Sun, you need to give 
us a solution to this.  The Microsoft developers are laughing 
at us (you) as we are faced with releasing Java app products 
with this type of repaint problems.

java version "1.4.0_00"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.0_00-b05)
Java HotSpot(TM) Client VM (build 1.4.0_00-b05, mixed mode)

The printdialog still does not repaint as of today Dec 04
2002.

This still happens in 1.4.2-b28 (regression?)

Its fixed in 1.5 (not yet released). The bug database used to
say something like "fixed in a future release" for cases
like this,
but it doesn't any more.
I will try (again!) to get that issue resolved.