|
Quick Lists
|
|
Bug ID:
|
4515058
|
|
Votes
|
0
|
|
Synopsis
|
application does not exit after printing
|
|
Category
|
java:classes_awt_im
|
|
Reported Against
|
merlin-beta3
|
|
Release Fixed
|
|
|
State
|
11-Closed,
Will Not Fix,
bug
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
4671025
,
4844504
,
4670707
|
|
Submit Date
|
16-OCT-2001
|
|
Description
|
An application does not exit after printing is completed. This bug is occuring in merlin build 82 in solaris 8. It can be seen in the attached program.
How to reproduce the bug :
Compile and run the program. Close the program without doing anything. The program will exit cleanly. Now, run the application again and click on the print button. Click on the print button of the printdialog that comes up. Close the window. The frame gets closed but the application does not exit back to the command prompt.
import java.awt.*;
import java.awt.event.*;
import java.awt.print.*;
public class MultiplePrinting implements ActionListener{
final Frame TstFrm = new Frame("Test Frame");
Button PrnBtn = new Button("Print");
public static void main(String []args){
MultiplePrinting Mtp = new MultiplePrinting();
}
public MultiplePrinting(){
TstFrm.addWindowListener(new WindowAdapter(){
public void windowClosing(WindowEvent we){
TstFrm.dispose();
}
});
PrnBtn.addActionListener(this);
TstFrm.add(PrnBtn,BorderLayout.SOUTH);
TstFrm.setSize(100,100);
TstFrm.setVisible(true);
}
public void actionPerformed(ActionEvent ae){
JobAttributes JbAtrb = new JobAttributes();
JbAtrb.setCopies(2);
JbAtrb.setDialog(JobAttributes.DialogType.NATIVE);
PrintJob PJ = Toolkit.getDefaultToolkit().getPrintJob(
TstFrm,"Testing Multiple", JbAtrb,null);
if (PJ != null){
Graphics G = PJ.getGraphics();
if (G != null){
G.setFont(new Font("Dialog", Font.BOLD, 16));
G.setColor(Color.black);
G.drawString("Page 1" , 100, 40);
}
G.dispose();
}
PJ.end();
PJ = null;
}
}
xxxxx@xxxxx 2001-10-16
I have inadvertently put the build as 82. The bug is reproducible in build 83 as well
|
|
Work Around
|
public MultiplePrinting(){
TstFrm.addWindowListener(new WindowAdapter(){
public void windowClosing(WindowEvent we){
TstFrm.dispose();
System.exit(0); // force application exit
}
});
|
|
Evaluation
|
Work-around provided.
xxxxx@xxxxx 2001-10-16
This is possibly not a bug; it is certainly not a regression, since it happens in 1.3.1. I am passing it on to 2D to evaluate further.
xxxxx@xxxxx 2001-11-06
This has nothing to do with 2D and it isn't a bug. If you comment out all of
the code inside of actionPerformed (so that it does not call PrintJob at all),
it still doesn't exit. The event thread is still going to be around. The
user must explicitly call System.exit() if he/she wishes to stop an AWT app.
This is probably a dup of another AWT bug. I will let AWT close it.
xxxxx@xxxxx 2001-11-07
The application doesn't exit as showing print dialog causes
the input method composition window to be shown. Here is the stack
trace indicating the point where the peer is created:
at java.awt.Frame.addNotify(Frame.java:472)
at java.awt.Window.pack(Window.java:416)
at sun.awt.im.CompositionArea.<init>(CompositionArea.java:74)
at sun.awt.im.CompositionAreaHandler.<init>(CompositionAreaHandler.java:53)
at sun.awt.im.InputMethodContext.getCompositionAreaHandler(InputMethodContext.java:196)
at sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:178)
at java.awt.Component.dispatchEventImpl(Component.java:3477)
at java.awt.Container.dispatchEventImpl(Container.java:1440)
at java.awt.Component.dispatchEvent(Component.java:3368)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:193)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:147)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:137)
at java.awt.Dialog.show(Dialog.java:527)
at java.awt.Component.show(Component.java:1131)
at java.awt.Component.setVisible(Component.java:1086)
at sun.awt.print.PrintDialog.display(PrintDialog.java:520)
at sun.awt.print.PrintControl.displayCommonDialog(PrintControl.java:462)
at sun.awt.print.PrintControl.displayNativeDialog(PrintControl.java:511)
at sun.awt.print.PrintControl.displayDialog(PrintControl.java:418)
at sun.print.PrintJob2D.printDialog(PrintJob2D.java:160)
at sun.awt.motif.MToolkit.getPrintJob(MToolkit.java:418)
at MultiplePrinting.actionPerformed(MultiplePrinting.java:30)
at java.awt.Button.processActionEvent(Button.java:384)
at java.awt.Button.processEvent(Button.java:353)
at java.awt.Component.dispatchEventImpl(Component.java:3527)
at java.awt.Component.dispatchEvent(Component.java:3368)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:193)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:147)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:141)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:133)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:101)
The AWT will not shutdown until all peers are disposed.
The input method composition window is never disposed, so AWT never
shuts down and the application never exits.
xxxxx@xxxxx 2001-11-08
======================================================================
This problem seems to have broken the fix for 4030718. We ought to address
it as soon as we can.
xxxxx@xxxxx 2001-11-08
No, 4030718 isn't broken. I spent a little while chasing this. First of all,
I wasn't able to reproduce it on WindowsNT with merlin build 86 (the latest).
Second, I was able to reproduce it on sparc all the way back to merlin-beta build 64 - the oldest one I could find. So, it doesn't appear to be a
regression of any kind. We should still try to fix it in an upcoming release,
though.
xxxxx@xxxxx 2001-11-15
======================================================================
Changed the composition area code to delay the creation of the window until it is actually required to get shown. So no peer is recorded in the map in this case.
xxxxx@xxxxx 2001-11-19
======================================================================
The problem does not happen with the change above for the host input method, but there still is the problem if the user uses the Java input method. Changed back to the committed state.
xxxxx@xxxxx 2001-11-19
After a long discussion with Danila, we have agreed to close this bug as "will not fix", as there is no complete way to fix this problem without changing AWT and IMF specs. Two new RFEs are filed against AWT (4670707) and IMF (4671025). Please see Comments section for the entire email discussion.
xxxxx@xxxxx 2002-04-18
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |