George as purposed by Ed Rauh i'll pass you this message. Maybe you can give me some insights

>Ed,
>
>Since, you're an expert here when it comes to api's :), i've got a question regarding setting printersettings with API's:
>

I haven't done anything yet with the printer APIs in VFP, so I may be less than helpful.

>I've been looking for a way to make a custom printer (prompt) dialog box from which you can change the printer properties (with the Documentproperties API) Though its rather simple to store this information into a report (since the TAG2 field in a report is in fact a DEVMODE structure) there is no way of controlling that a report uses all of the set properties
>
>For example: If i set the driver not to print colors, it stil uses colors when i store the devmode structure in Tag2 and print the report. But when i set the driver to print landscape this will succeed.
>
>I can't make the changes made by documentproperties permanent since the customers on a network may not have persmissions to change the documentproperties.
>

A couple of SWAGs; I have not tried either approach myself.

The first looks to be the easiest approach if it works, and the report isn't embedded in a .EXE or .APP file. What about making a local copy of the .FRX/FRT files at runtime, and then hacking the TAG2 structure locally? You couldd then run report from the local copy rather than the shared image, with the DEVMODE structure you've hacked in place...

The second approach would be to rip out the DEVMODE structure and force it to be in place the way you want it as the first thing done in the report header with a UDF. I'm not certain that VFP uses the DocumentProperties() API call - it might well be using SetPrinter() instead; you can set default properties for a session with SetPrinter() at level 2 via a PRINTER_INFO_2 structure, which takes a pointer to a DEVMODE structure as a member. This might also be a way to force VFP to set print modes not directly supported by the report designer.

You might well need to clean up the printer's state after the report finishes. You can grab the state of the printer with GetPrinter() at level 2, and save the PRINTER_INFO_2 structure. I'd also save everything pointed at by the PRINTER_INFO_2 structure and reallocate them to new string buffers (CLSHEAP can handle the allocation task, and the new AllocString method makes coding to save a string cleaner than making separate calls in your code to Alloc and CopyTo), adjusting the embedded pointers in the saved PRINTER_INFO_2 before calling SetPrinter() at the end to restore the state.

I've just recently started toying with GetPrinter()/SetPrinter() as a demonstration of CLSHEAP, so I'm not at all certain that this approach will do what you want; it's worth a shot if the first method fails.

As mentioned, I haven't tried either of these. You might ask George Tasker if he's got any insights into the relationship between VFP's report engine and the printer API.

TheWindows NT WIN32 API SuperBible devotes about 70 pages to the various printer APIs; you might find it helpful if you decide to try using the API.