Just a couple notes:

>*!* use cust
>*!* go top
>*!* set print off not necessary
>*!* set printer to myfile.txt
>*!* set device to print not necessary
>*!* set printer on
>*!* set console off
>
>*!* scan
>*!* ??trim(cust.cusname) at 1
>*!* ??trim(cust.add) at 25
>*!* ?
>*!* *??? chr(10)
>*!* endscan
>*!* use
>*!* set printer off
>*!* set printer to
>*!* set console on

SET DEVICE TO ... tells (V)FP where to send @ SAY commands. Which you're not using. SET PRINTER ON and SET CONSOLE OFF are the only needed commands for affecting ? and ?? (and \ and \\, and LIST commands, etc., etc.)

>The ??? just kills the file. In any case, I believe I have found a way out of my problem though using the ? and ?? commands. Let me give you some more background on what I am trying to do so you can appreciate the situation I find myself in. We are currently in Fox DOS and in our program contains over 500 legal documents coded in the FoxPro report writer liberally sprinkled with printer control codes. I have no interest in recoding all these reports in the Visual Foxpro report writer. I plan to programatically convert the report files to prg files and print them using rawprint. I have jumped through hoops trying to get the control codes to work correctly. I believe someone could make a good deal of money if they came up with a class or dll or whatever to automate this process. I can begin to see the light at the end of the tunnel but it remains very small. Thanks for your help.

Boy. I've been in a similar spot recently but with many fewer reports ... and some of the reports were in PRGs, and a few were in FPD Report Writer. But they all had printer codes hard-coded into them, rather than using the resource file to set up the printer, which was the "right" way later in FPD's life. My solution was to observe what the reports did, and reproduce the appropriate fonts, sizes and styles in VFP report writer. Obviously you don't want to do that for 500 reports that need to be done quickly.

But in the long run, the sooner you get these reports into Report Writer, the farther ahead you'll be in future maintenance. Maintaining hard-coded (prg) reports will be a super bitch for the rest of the app's life, especially when there are hard-coded escape sequences in them which are specific to a certain printer. What happens if the company switches printers? You have to go through all the codes and convert them the hard way again, looking at the first printer manual to figure out what the existing codes meant, and the second printer's manual to figure out what to convert them to.

You're in a hard choice situation. If there's any possibility of convincing everyone involved that the reports need to be moved to Report Writer, it'll save your future if you do so.

Cheers,
Rich.