Roxanne,

>>1) It strips all the printer specific crap from the FRX.
>>2) It provides a wrapper around the low level API printer calls. Anything exposed by the printer driver can be controlled.
>
>oh... so ok, it would of worked for me then. Thing is this is a rush job and I've already dealt with enough dll hell that I just dont want to pull in one more dll at this point. I'll make note though of this info you gave me for next release, thanks!
>
>And for the record, doing the Crystal oReport.PrinterSetup(0) did allow me to still keep my spec's promise of providing printer setup manipulation. So it fixed my problem without resorting to another dll. But one caveat... Crystal's PrinterSetup() method does an implicit PrintOut() when you click OK button. So downside was I lost a separated print setup step, but we can live with that. I thought this was kinda dumb though, especially since I can do PrintOut(1) and get prompted for number of copies and print range, seems to me that shouldnt of been coupled but oh well.

AFAIK the printerSetup was added in CR 8.0, and like you, i was not too happy with the implementation of it. Since I work with CR 7.0 most of the time, I decided to write my own print dialog. Without trying to force you to look into Focus.fll, this library provides you all the print info you need to write your own print dialog.

I don't know the PowerPrint solution to well, but I don't like the idea to change printersettings in Windows. This might affect other windows programs. Just retrieve the info you need (Printername, PrinterDriver, Printerport, etc.) and set these properties in the report object is a far more clear solution IMO.