And there's your problem. You're allowing control of the printstream to pass outside of VFP. I liken it to getting into a cab and saying "Take me to the airport" - you have just passed control of the route to the driver of the taxi, but if you get in that cab and say "Take me to the airport via (insert route here)" - you still get to the airport, but you get there the way you wanted to get there (or, you got thrown out of the cab by a very PO'd cabbie).

Yes, when you use PROMPT, you get the 'standard Windoze' way of selecting a printer and absolutely no clue of which printer was selected because you choose not to know and Windows knows this and it'll take care of your print and pat you on the head and tell you 'good dog'.

If you're wanting "know the route", then you're going to have to specify the route.


>What I mean by separate interface is this: If you want to let the user choose a default printer to use for your app, you have to develop an interface like you mentioned. But when you use the PROMPT keyword, you get the standard "Windows way" of selecting a printer. So these are the two interfaces for the same function. If you could find out what printer they decided to print to, you could do away with the need for a separate interface like you've developed.
>
>I find that users do want to print to other printers. I'm sure it varies greatly depending on the company, but when you have multiple network printers, there are usually reasons for that other than just having one near this dept and one near that dept, etc. They may have an invoice printer, a reports printer, an impact printer for special forms, etc. Again, it varies depending on the company. And, when it comes down to it, this is not that big of a deal, but it would be nice to be able to determine which printer a user printed to when they select it from the Windows printer dialog. At present, I know of no way to do that.
>
>
>>Assuming that there is some type of User table in existance (or one can be created) how big of PITA would it be to just save the last printer they used? Then the application could remember what printer was used last and display it as the default selection next time the used wants to print something - unless they're going through the "Select Printer" options in some other fashion than your application.
>>
>>As far as a separate interface for this, I'm not seeing that issue. I used to have an object that was nothing more than 3 radio buttons - Print to 1) Screen 2) File 3) Printer (with a drop list of the printer names with the default printer displayed at the top when this option was selected).
>>
>>Another question I would ask, however, is: Does the user WANT to set a 'default Fox' printer other than their default Windows printer. In my experience, users generally liked the option of printing to another network printer - but actually doing so was a rare instance.
>>
>>>Getting the default printer name is no problem. What is a problem is remembering what printer a user printed to. By that, I mean that if the user has printer 1 set as default, but prints something and chooses printer 2, I'd like to be able to determine that they printed to printer 2 and bring that up as the selected printer next time they print. Can't do it. The default printer has not changed, so the next time they print it will come up as the selected printer. You can use SET PRINTER as you mention, but you have to have a separate interface for this. If they set it to printer 2 via this technique, then they print to printer 3, you can't "remember" that and bring up printer 3 as the default printer the next time because you can't tell what printer they printed to. You're always hamstrung by not knowing the printer they actually printed to, which may not be the default and may not be the one that was set with SET PRINTER.