Community
Participate
Working Groups
Created attachment 239799 [details] File demonstrating the behavior In my application, I wish to print a complex document that requires some computation to set up each page. The attempted approach was to create a printer job, then periodically call Display.readAndDispatch() to keep the display active. Unfortunately, as soon as a print job exists, I am no longer seeing any updates to the screen. Attached is a modified version of the progress bar snippet (57) that shows the bug. When you run the snippet, the progress bar proceeds normally until you click the button to start a new print job. After pressing the display freezes. Clicking the button again cancels the job and the display becomes active. I would expect that having a print job active would not impact the behavior of the main display.
Abhishek, can you please try the test snippet ? Thanks.
(In reply to Adam Briska from comment #0) > Created attachment 239799 [details] > File demonstrating the behavior > > In my application, I wish to print a complex document that requires some > computation to set up each page. The attempted approach was to create a > printer job, then periodically call Display.readAndDispatch() to keep the > display active. > > Unfortunately, as soon as a print job exists, I am no longer seeing any > updates to the screen. > > Attached is a modified version of the progress bar snippet (57) that shows > the bug. When you run the snippet, the progress bar proceeds normally until > you click the button to start a new print job. After pressing the display > freezes. Clicking the button again cancels the job and the display becomes > active. > > I would expect that having a print job active would not impact the behavior > of the main display. A call to startJob() on a Printer object must be followed by endJob() somewhere down the line, with the actual printing in between. The documentation on startJob() explains this in some more detail. And of course, you can move the printing part of your code to a separate thread if its going to hold up UI for too long.
I tested the attached snippet on Linux and the progress bar continues to update even after the printer job is started. This could very well be a problem with the Cocoa printing API itself but we need to confirm that.
(In reply to Arun Thondapu from comment #3) > I tested the attached snippet on Linux and the progress bar continues to > update even after the printer job is started. This could very well be a > problem with the Cocoa printing API itself but we need to confirm that. That's very likely true. I've tested, and it works fine on Windows 7 as well. However, without an endJob(), printing won't go through, atleast on Mac. I tested with Snippet132, after commenting endJob(), and it doesn't work. I don't see much use of fixing this issue if printing is not going to work with this code(without endJob()) anyway.
(In reply to Abhishek Kishore from comment #4) > (In reply to Arun Thondapu from comment #3) > > I tested the attached snippet on Linux and the progress bar continues to > > update even after the printer job is started. This could very well be a > > problem with the Cocoa printing API itself but we need to confirm that. > > That's very likely true. I've tested, and it works fine on Windows 7 as > well. However, without an endJob(), printing won't go through, atleast on > Mac. I tested with Snippet132, after commenting endJob(), and it doesn't > work. I don't see much use of fixing this issue if printing is not going to > work with this code(without endJob()) anyway. Agreed. Adam, please mention if you're fine with closing this bug as Printer#endJob() is necessary for a successful print job anyway and adding the endJob() call makes this bug go away.
Resolving this. Please reopen if you have problems with the suggested approach.
Re-opening. (This is also in my observation a Mac-specific bug.) Consider code like the following: printer.startJob(); while( havePages() ) { sendPageToPrinter(); while(Display.getCurrent().readAndDispatch() ); } printer.endJob(); In this example, the display will not update during the duration between startJob and endJob, even with the calls to readAndDispatch(). In my application, the act of printing may take several seconds, and during this time, the application appears to have hung.
(In reply to Adam Briska from comment #7) > Re-opening. > > (This is also in my observation a Mac-specific bug.) Yes, looks like it is. > > > Consider code like the following: > > printer.startJob(); > > while( havePages() ) { > sendPageToPrinter(); > while(Display.getCurrent().readAndDispatch() ); > } > > printer.endJob(); > > In this example, the display will not update during the duration between > startJob and endJob, even with the calls to readAndDispatch(). > > In my application, the act of printing may take several seconds, and during > this time, the application appears to have hung. And you're not fine with running your print job on a different thread?
> > And you're not fine with running your print job on a different thread? Much of the printing code re-uses the same code that was used to draw the display in the application, hence much of it is built on SWT controls that do not work on the non-UI thread. It seems surprising to me that the presence of an active print job would interfere at all with the normal function of the UI.
(In reply to Adam Briska from comment #9) > > > > And you're not fine with running your print job on a different thread? > > Much of the printing code re-uses the same code that was used to draw the > display in the application, hence much of it is built on SWT controls that > do not work on the non-UI thread. > > It seems surprising to me that the presence of an active print job would > interfere at all with the normal function of the UI. Is there a snippet of code that you can provide where the printing code re-uses code that must be executed in the UI thread?
Resolving this. Please reopen when you've a response to comment 10.
