>>>FYI: Not that it helps you, but they did get it right in 3.0b. This version of VFP had a getprinter() function that looked the same as sys(1037) and it of course returned the name of the printer. Strange that they would actually remove functionality from a function.
>>
>>Figures. But thats just what I'm trying to avoid. Removing functionality. Our users have gotten used to seeing where a report is going before actually printing. Oh, well...
>
>Hmmm...I'm thinking in theory all this info has to be stored in the registry. If so, in theory you could modify the default printer and it's settings, print the report, then set them back. I'll test my theory tomorrow if I get a chance. I wonder if there's a document somewhere that covers all the standard registry entries.

There really must be some kind of documentation. I'm just a little bit leary of reading/writing the registry. IMO, I think the registry is a bit dangerous to just be having any program modifying at will. There should be some kind of OS "blackbox" routines/objects for handling it. Maybe there is, but it doesn't appear that way to me. I still think it's rude for a program to change the "windows default" anything to suit its needs, no what the reason may be.
All "this application only" stuff must be out there somewhere, but it probably only exists as some kind of structure in memory, and doesn't exist in a permanent location like the registry. If you need to screw with anything, THAT'S what they should let you have access to. That would certainly be less dangerous to the system as a whole. At least if you did screw up the memory structure, you may only crash the one application, not render your whole machine useless because the registry got trashed and won't even boot up!