There is an inconsistency with the modality of print dialogs and app repainting
between the Solaris and win32 ref ports.

I've attached a testcase which shows this problem on 1.1.8, and 1.2.
Run the app, scribble in the frame, right click over the frame, and select
print. Move the dialog around to see the problem.

On win32 you can still select the File menu, and no repaint takes place.
On Solaris you can't select the File menu, and the is repainting.


> A print dialog is created when a print job is obtained from the default
> toolkit.
> This creates the print dialog. Note in the AWTMasterPrintergraphics class in
> the Win32 code says that the dialog is not modal - even though in Java the
> parent has been passed in.
>
> In the TestCase, the PrintJob is being created when as result of an
> ActionEvent. It is therefore being created on the EventDispatchThread, this
> then blocks on entry to native code.

> Under Solaris reference implementation, the print dialog has a peer
> implementation, so it therefore has a proper modality implementation.
>