Senin, 13 Agustus 2012

[MS_AccessPros] Re: Assigning printing setting through API

 

OK, I'm surprised you can't set Papersizes > 256 but I see thre are one or two esoteric Settings which you seemingly can't set through the Printer Object.

--- In MS_Access_Professionals@yahoogroups.com, "mivanek" <mirkosluv@...> wrote:
>
> Again, thank you, using Printer object is unfortunately not an option, since it lacks many features required with this printing functionality, like, for example, use of custom paper sizes (PaperSize 256 or above) and some other printer specific options not wrapped with Printer object. In reality it must match all printing options user can select on PageSetup dialog (including Printer related) and Printer object reflects only part of them, so using prtDevMode is the only way, for now setting system printer and applying it to reports on-fly (in preview, hidden and then sending it to print...)
>
> Pursuit goes on... :)
>
> --- In MS_Access_Professionals@yahoogroups.com, "acravenrohm" <yahoo@> wrote:
> >
> > Miroslav, to coin a hackneyed phrase "yes you can",
> >
> > in the same way that I set Monochrome (here I'm paraphrasing, not copying from the code)
> >
> > DoCmd.OpenReport RepName, acViewPreview, , WHERECONDITION, WindowMode, OpenArgs
> >
> > With Reports(RepName).Printer
> > .ColorMode = acPRCMMonochrome
> > .Duplex = acPRDPSimplex
> > .Orientation = acPRORLandscape
> > 'checkout the Printer Object for more Properties, such as PaperBin ;-)
> > End With
> >
> > RunCommand acCmdPrint
> >
> > --- In MS_Access_Professionals@yahoogroups.com, "mivanek" <mirkosluv@> wrote:
> > >
> > > Hi and thank you for jumping in. What I meant with creating reports on-fly was not that "design" changes are done to object itself, but it's controls and their properties etc are controlled by customized user settings (basically each and every control on the report is controlled that way). Actual report objects are not, indeed, created on-fly, as a "templates" they do exist and do not get "design" changed, under report I meant what's displayed/printed according to user customization.
> > >
> > > Back with Acc97, when there was not Printer object at all, this was all nicely done via API and worked like a charm, problem is now that app (front-end) needs to be delivered as .accde and modifying underlying prtDevMode through Access is not an option any more, so was hoping somebody would know how to do it through API. I guess it should be possible, since Access dialogs (Print and Page Setup for example) can do it, how would anybody select printing options from preview otherwise...? And one can confirm that Page Setup dialog changes prtDevMode members while report is in preview mode. So, it's not "natively" read-only and could not be, it's just that MS decided to protect it in all modes except design.
> > >
> > > Anyway, I would of course be interested to see how you do it, but I'm not sure Printer object supports all required properties, like trays, duplex printing and various other options one could control through prtDevMode.
> > >
> > > Again, all replies are welcome, but keep in mind it needs to run in compiled db (.accde) and yes, in run-time.
> > >
> > > Thanks in advance
> > >
> > >
> > >
> > > --- In MS_Access_Professionals@yahoogroups.com, "acravenrohm" <yahoo@> wrote:
> > > >
> > > > 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