Miroslav-
Just a few thoughts...
Is the user setting different options for any given report depending on the task
at hand? For example, sometimes the report must be sent to printer A and other
times to printer B in duplex. If that's the case, then your dynamic assignment
is the only way to go in a .accde. What sorts of things could "go wrong" to
prevent your code from putting it back after printing? Perhaps an appropriate
error trap will solve that.
If, however, a given report must always go to a specific (non-standard) printer,
consider defining that printer in Design view of the report and saving the
report before you create the .accde. The one difficulty to this procedure is
the case where different users want a given report to go to different locations.
That would mean creating a specific .accde (with the appropriate printer
settings) for each user. Could be a management nightmare to keep track of which
.accde goes to which user.
John Viescas, author
Microsoft Office Access 2010 Inside Out
Microsoft Office Access 2007 Inside Out
Building Microsoft Access Applications
Microsoft Office Access 2003 Inside Out
SQL Queries for Mere Mortals
http://www.viescas.com/
(Paris, France)
-----Original Message-----
From: MS_Access_Professionals@yahoogroups.com
[mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of mivanek
Sent: Friday, August 10, 2012 6:53 AM
To: MS_Access_Professionals@yahoogroups.com
Subject: [MS_AccessPros] Assigning printing setting through API
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
------------------------------------
Yahoo! Groups Links
Tidak ada komentar:
Posting Komentar