You got that right. All this for a customer who thinks his form report should print as fast as his old dbase program.

thanks for checking into it. I'm on NT workstation.

If I don't get this to work I'll go back to my .frx. In the meantime, my problem with the .frx is that it prints fairly slow in all fonts unless I select the 'generic/text only' printer driver for the dot matrix printer. It prints much faster, but it sometimes drops fields or prints them out of order. The report previews just fine, so it has to be a driver issue. I may end up just going back to the standard printer driver and tell the customer that he's gonna have to live with the speed issue. I'm spending WAY too much time on this...

>Hmmm...now I'm perplexed. Isn't it truism that the most difficult problems are those that should be easily resolved?
>
>This is the code I always used. I haven't done this type of printing in VFP but I don't see why the behavior would not be the same.
>
>I'm going to test this when I get back to my office and have access to VFP. I'll let you know what results I get (under NT Server).
>
>
>>I can't win. This doesn't work in command window or in form code. However, if I remove the SET PRINTER TO (printer name), it works in the commmand window, but that's it.
>>
>>>You're missing the SET PRINTER commands that set and reset the printer, creating a print job. Try the following instead:
>>>
>>>SET PRINTER TO LPT1: (or windows printer name)
>>>SET DEVICE TO PRINT
>>>@ 2,46 SAY 'test'
>>>SET DEVICE TO SCREEN
>>>SET PRINTER TO
>>>
>>>In a PRG, by the way, you would want to add SET CONSOLE OFF before SET PRINTER... and SET CONSOLE ON after the last SET PRINTER.
>>>
>>>
>>>
>>>>
>>>>I tried this in the command window and a PRG:
>>>>
>>>>SET DEVICE TO PRINT
>>>>@ 2,46 SAY 'test'
>>>>SET PRINT TO
>>>>SET DEVICE TO SCREEN
>>>>
>>>>and it sends output to printer as I would expect in both cases. However, if I call this PRG from another PRG or even place this code within a form method, nothing happens when this code fires. I traced it through the debugger, the code is being executed, but no output is sent to the printer. I then issue the above commands in the command window and I get my output correctly. What am I missing here?
>>>>
>>>>>Hiya Jim ----
>>>>>
>>>>>It has more to do with the way Windows and/or the network works. The entire print job is released to the printer at once. It makes sense when you think about the way a network has to manage resources.
>>>>>
>>>>>So, the practical solution is to SET PRINTER TO {whatever} before the @..SAYs and SET PRINTER TO {blank} afterward and the entire job spools to the network. You're not going to find a way to do it line by line and that would, indeed create some messy situations if someone else sent something to that printer.
>>>>>
>>>>>
>>>>>>I'm not an old dbase guy (just happen to have an old dbase report I'm rewriting), so I'm asking this out of ignorance. When I run dbase 3 in windows I can issue SET DEVICE TO PRINT and immediately see output directed to the printer line by line with @...SAY (Output is not spooled). Am I forced to spool output with VFP? I guess there's nothing wrong with that, I just assumed I'd see the same output behavior as DBASE.
>>>>>>
>>>>>>>Hiya Rich ---
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>You sort of answered your own question here.
>>>>>>>>
>>>>>>>>SET PRINT ON redirects @...SAY to the printer. (SET DEVICE TO PRINT redirects ? commands to the printer. Or did I get them backwards?)
>>>>>>>>
>>>>>>>
>>>>>>>You've got them backwards but, hey, not bad for memory of old stuff.
>>>>>>>
>>>>>>>>SET PRINTER TO [anything] flushes the printer buffer. FoxPro buffers direct output to the printer until you change printers (or pretend to).
>>>>>>>>
>>>>>>>
>>>>>>>Eloquently stated.