Community
Participate
Working Groups
Build Identifier: Version: Indigo Service Release 1 Build id: 20110916-0149 Before open PrintDialog (org.eclipse.swt.printing.PrintDialog), you can set PrinterData Object to dialog by calling PrintDialog.setPrinterData(PrinterData data). But Dialog will ignore PrinterData's value(orientation, copyCount, etc.) and it appears as default value(of Printer Driver). It happens when PrinterData object intitated by Printer.getDefaultPrinterData() or Printer.getPrinterList(). (so you can avoid this problem by initiating object using new PrinterData()) Reproducible: Always Steps to Reproduce: Here's short snippet: It doesn't works: ------------------------------------------------------------- PrintDialog dialog = new PrintDialog(new Shell()); PrinterData printerData = Printer.getDefaultPrinterData(); printerData.orientation = PrinterData.LANDSCAPE; dialog.setPrinterData(printerData); dialog.open(); -------------------------------------------------------------- Altough you set PrinterData's orientaion as LANDSCAPE, it ignored and appears as driver's default value. You can avoid this problem by using PrinterData printerData = new PrinterData(); instead of PrinterData printerData = Printer.getDefaultPrinterData();
Created attachment 210485 [details] Snippet to test bug. Snippet to test bug. If you press "open print dialog" button, 1. it initates PrinterData object by Printer.getDefaultPrinterData(); 2. change orientaion as you selected. 3. set PrinterData object to PrintDialog. 4. open the PrintDialog. But dialog will ignore your selection and appears as default value.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
