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
Tidak ada komentar:
Posting Komentar