I'm trying to solve issue with reports in Access 2010, where complex printing settings must be applied to document on-fly. In short, users have option to define and save specific printout scenarios and then assign them to particular documents so that when they click print, depending on those settings output will go directly to various printers, use various printing options/setting etc.
All fine with collecting "printing scenarios" and saving them (saving prtDevMode structure members since Printer object does not reveal all properties), all fine. Also, all fine with even the whole task, but somehow I think it's going wrong path. Application (front end) must be in a compiled state (accde), so there is no option to modify prtDevMode property (available only in design mode) and at the very moment this process is done by modifying system printer through API (something like described here: http://support.microsoft.com/kb/230743 ) and then this printer is assigned to report opened hidden, in preview mode and then simply sent to printing (all done from code). So, for user it is all transparent, works as expected, aside for few things:
1. It is very slow, not surprising, we are modifying system printers.
2. There are issues with network printers and required rights (solvable, but can create problems).
3. If anything goes wrong before system printer is returned to previous state/settings, it is left with very specific options, often wrong for "normal" use(rs).
Does anyone knows if it's possible to modify/set report's (prt)DEVMODE structure through API, instead of applying/copying DEVMODE structure to printer and then assigning printer back to report? It seems to me we are going long way around and not sure it is actually needed.
I don't even know why is prtDevMode read-only except for design mode, since it would normally get modified "on-fly" by printing related dialogs. Or modifying any property of the Printer object will be reflected in change of prtDevMode structure itself, as well. Was this some kind of "safety feature" by MS and is there any way to bypass it? There must be, because system dialogs can do it and Printer object changes are reflected, all with accde and with report in preview. So, how to apply ready DEVMODE structure to report object via API? Can DocumentProperties function do it? Or I'm missing something?
Please help, even if only directing me to place with best chance to get an answer. Many thanks in advance
Miroslav
Tidak ada komentar:
Posting Komentar