Jumat, 10 Agustus 2012

[MS_AccessPros] Re: Assigning printing setting through API

 

Miroslav, I'm a little unsure how to reconcile the fact that you're running a runtime version and hence cannot change and save the PrtDevMode with the fact that you are creating the reports "on-the-fly".

However, I do a number of things, in runtime, using the Report/Form.Printer and Application.Printers() which might be enough for you and your users. (For example, in one case the print margins for a card-printer are controlled through INI Values and in another case I set the report to print Monochrome when the printer settings are to print Monochrome, otherwise Access ignores this setting and prints full-colour.)

I, personally, would hate it if an application kept changing my default printer settings so I try to avoid doing it in my applications ;-)

--- In MS_Access_Professionals@yahoogroups.com, "mivanek" <mirkosluv@...> wrote:
>
>
> John, thanks, quick answers
>
> > Is the user setting different options for any given report depending on the task at hand?
>
> Yes, each report is actually even created on-fly through various user customization, in reality saved object is mere "template". One of the customized options is defined printing scenario, so each physical report can in reality have number of variations and on-fly setting is the only way to do it.
>
> In reality I'm not that much concerned with eventual issue of system printer remaining custom set, more with the fact that process as it is now appears to be "going long way around", causing slow operation, while in the same time I can see that "system" can do all the tasks needed, it's just that MS decided to not allow report's prtDevMode to be modified, except in design mode, for questionable reasons.
>
> So, I'd want to do what system dialogs can do, or what exposed Printer object can also do, modify it in preview-mode. I hope system is not doing it the way it's done in my application currently. Being reserved space with each object prtDevMode structure data gets saved even with compiled db (accde), it's not that structure itself would change and it's "only" to find how it could be done through API. It would be WAY safer, faster and with less steps where something could go wrong.
>
> In the end, it should "just" be a memory space, which we could maybe write to replacing current data, right? Or would approach like that be sure to GPF the system?
>
> Thanks for all the insight and/or direction
>
> Miroslav
>

__._,_.___
Recent Activity:
.

__,_._,___

Tidak ada komentar:

Posting Komentar