Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 296594

Summary:	SWT Printing overrides system's printing settings
Product:	[Eclipse Project] Platform	Reporter:	Benjamin Judas <judas>
Component:	SWT	Assignee:	Platform-SWT-Inbox <platform-swt-inbox>
Status:	CLOSED WONTFIX	QA Contact:	Praveen <pinnamur>
Severity:	normal
Priority:	P3	CC:	carolynmacleod4, cocoakevin
Version:	4.0	Keywords:	triaged
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Benjamin Judas

2009-12-01 12:38:23 EST

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Build Identifier: 20090619-0625

We are administering a Java-Application which needs to print two forms, each on a different paper-type.

Since SWT doesn't allow to select a specific source-tray to use for printing, we used to have a little workaround by setting up two driver-instances in the windows print-manager pointing to the same physical printer.

One instance was set to "Fetch from integrated tray" while the other was set to "Fetch from universal tray" (single sheet feeding). Then we would simply create two Printer-Objects for these two windows driver instances. This worked fine for swt-3.4.0.v3448f, but somehow doesn't with 3.5.1 anymore.

Strangely, examining the windows print services I can see that printing is in fact assigned to the correct driver-instance, but the driver simply doesn't care and fetches from it's default tray.

I was able to pinpoint the problem to the version difference. I even tried the SWT-3.6 Milestone, but this shows the same behaviour as 3.5.

I am filing a bug because SWT should not override the printer-settings and instead respect what is setup in the system's printing system.

P.S.: Of course, if somebody could provide another workaround/idea considering this problem, I'd be open for that, too.

Reproducible: Always

Steps to Reproduce:
n/a

Comment 1 Benjamin Judas

2009-12-02 08:26:36 EST

I found another interesting fact:

When fetching the printer from the systems Printer enumeration (i.e. via Printer.getPrinterList()), the aforementioned problem exists, i.e. the printer would print from its default tray instead of fetching from the manual feeder.

But retrieving the PrinterData-object via a PrintDialog and then simply selecting the printer-instance for the manual feeder, the printer would fetch from the correct tray.

Taking a look at both PrinterData's (i.e. the one retrieved via getPrinterList() and the one retrieved via the PrintDialog) shows that the latter ones "otherData" would be filled, while the first ones would be empty.

However, I cannot display the dialog since we have some.. err.. "incompatible" users who would be totally stressed if an unknown dialog would come up.

But maybe this additional information helps.

Comment 2 Kevin Barnes

2010-01-06 15:11:10 EST

Praveen, please investigate.

Comment 3 Benjamin Judas

2010-07-09 09:10:57 EDT

Hi again,

After about seven months I'd like to ask about the status regarding this bug.

Regards,
Benjamin

Comment 4 Leo Ufimtsev

2017-08-03 12:30:32 EDT

This is a one-off bulk update. (The last one in the triage migration).

Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process:
https://wiki.eclipse.org/SWT/Devel/Triage

See Bug 518478 for details.

Tag for notification/mail filters:
@TriageBulkUpdate

Comment 5 Eclipse Genie

2020-08-22 12:41:37 EDT

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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.

--
The automated Eclipse Genie.