EDN Admin
Well-known member
My application allows users to specify their own paper sizes and other printer attributes and design reports for them. It all works well for paper sizes built-in to the printer driver, and for orientation, paper source and duplex options (using the
DocumentProperties() technique described in http://support.microsoft.com/kb/167345/en-us ). But for paper sizes which do not appear in the list of sizes supported by the driver (based on querying it with
DeviceCapabilities() and DC_PAPERS and DC_PAPERSIZE), Ive had only limited success.
Some drivers, like the HP9000 Laserjet, allow the user to define a custom form which then shows up in the list of supported paper sizes returned by
DeviceCapabilities() . But most drivers, for example the Brother HL-5250DN Laser, do not seem to support this method. However, the common
Devices and Printers > Print Server Properties interface allows users to create custom "forms", and it appears that an application should be able to then select a previously defined form using the
dmFormName field of the DEVMODE, directly analogous to selecting the paper size via the
dmPaperSize field. In fact, this method seems preferable, since it is more standard across drivers.
However, when I use the dialog to create a custom form, although it shows up in the
EnumForms() list (along with about 200 built-in "forms" equivalent to the predefined paper sizes), and the DM_FORMNAME bit is set in the
dmFields field (returned from the initial DocumentProperties() indicating that the driver supports it), and no error is returned when I set the
dmFormName field and use DocumentProperties() to update the driver (exactly as I do for other printer attributes), the driver appears to ignore the setting.
GetDeviceCaps(hdc,PHYSICALWIDTH) , for example, returns the previously established paper width, rather than the width of the custom form.
I cant tell whether this is a bug in the API, a bug in my app, or a misunderstanding in the procedure. The documentation seems unclear on whether the
dmFormName should be set by itself, or in conjunction with a particular
dmPaperSize value, such as 0 or 256, but Ive tried all the permutations without any difference in results.
Scanning the forums Ive found a couple of articles about setting custom forms, but they are all kind of old (mostly talking about differences between NT 4.0 and Windows 95), so it isnt clear how much of that applies still. Also, they tend to mention
using SetPrinter() in order to establish printer settings for other users/programs, whereas I only want to change them for the one print job. So I am not using
SetPrinter() . Perhaps this is necessary? Or is there some other trick required when setting
dmFormName that is different from the way other printer attributes, such as
dmOrientation or dmPaperSize , are set?
Ive also considered setting the dmPaperWidth (DM_PAPERWIDTH) and
dmPaperLength (DM_PAPERLENGTH) fields directly, but so far the only printer driver Ive found that supports that feature is a PDF writer, so that doesnt seem like a good approach for an app that must work on a wide variety of printers.
Is there perhaps a standardized virtual printer driver that can be used with a print preview or other non-physical output device to test whether an application is interfacing properly? Any suggestions appreciated! <hr class="sig Joaquin M
View the full article
DocumentProperties() technique described in http://support.microsoft.com/kb/167345/en-us ). But for paper sizes which do not appear in the list of sizes supported by the driver (based on querying it with
DeviceCapabilities() and DC_PAPERS and DC_PAPERSIZE), Ive had only limited success.
Some drivers, like the HP9000 Laserjet, allow the user to define a custom form which then shows up in the list of supported paper sizes returned by
DeviceCapabilities() . But most drivers, for example the Brother HL-5250DN Laser, do not seem to support this method. However, the common
Devices and Printers > Print Server Properties interface allows users to create custom "forms", and it appears that an application should be able to then select a previously defined form using the
dmFormName field of the DEVMODE, directly analogous to selecting the paper size via the
dmPaperSize field. In fact, this method seems preferable, since it is more standard across drivers.
However, when I use the dialog to create a custom form, although it shows up in the
EnumForms() list (along with about 200 built-in "forms" equivalent to the predefined paper sizes), and the DM_FORMNAME bit is set in the
dmFields field (returned from the initial DocumentProperties() indicating that the driver supports it), and no error is returned when I set the
dmFormName field and use DocumentProperties() to update the driver (exactly as I do for other printer attributes), the driver appears to ignore the setting.
GetDeviceCaps(hdc,PHYSICALWIDTH) , for example, returns the previously established paper width, rather than the width of the custom form.
I cant tell whether this is a bug in the API, a bug in my app, or a misunderstanding in the procedure. The documentation seems unclear on whether the
dmFormName should be set by itself, or in conjunction with a particular
dmPaperSize value, such as 0 or 256, but Ive tried all the permutations without any difference in results.
Scanning the forums Ive found a couple of articles about setting custom forms, but they are all kind of old (mostly talking about differences between NT 4.0 and Windows 95), so it isnt clear how much of that applies still. Also, they tend to mention
using SetPrinter() in order to establish printer settings for other users/programs, whereas I only want to change them for the one print job. So I am not using
SetPrinter() . Perhaps this is necessary? Or is there some other trick required when setting
dmFormName that is different from the way other printer attributes, such as
dmOrientation or dmPaperSize , are set?
Ive also considered setting the dmPaperWidth (DM_PAPERWIDTH) and
dmPaperLength (DM_PAPERLENGTH) fields directly, but so far the only printer driver Ive found that supports that feature is a PDF writer, so that doesnt seem like a good approach for an app that must work on a wide variety of printers.
Is there perhaps a standardized virtual printer driver that can be used with a print preview or other non-physical output device to test whether an application is interfacing properly? Any suggestions appreciated! <hr class="sig Joaquin M
View the full article