Yups Tracy, I know about those behaviors with REPORT FORM, but i didn't mean to do it by REPORT FROM... I was meaning use your @...SAY just as you did at FPD, but not sending to the printer, send it to a textfile. One you have your formatted texfile, send it to the printer via API. Is it acceptable?

>So far this works the best but it's still not acceptable. I like how it prevents the page ejection though. If I use REPORT FORM TO FILE ASCII it creates the text file and the copyfile API copies it to the printer but it drops off data somehow. This is still that pesky bug where using REPORT FORM TO FILE ASCII drops column headings. If I go in and look at the .txt file the missing data is NOT there also.


>>That's the bad news about it, DP4 doesn't use existing Visual FoxPro or FoxPro Dos reports, so, If you have a lot of reports to "convert" and need it "fast" this class is not your answer.
>>I've seeing another workaround, I don't know if it is fine for your, check this out:
>Frequently Asked Questions #7817 How do I copy a file to a printer port
>
>With this, you should have to send your @...SAY output into a file, then copy to the printer port...
>Hope this helps
>>Hi Again Esparta,
>
>>I'm looking at the DOSPRINT4 Help file and I guess I just am not quite sure why this is better than using @...SAY to print to a printer in dos? Our reports print fine on the Okidatas using @...say but we are trying to only maintain the report writer version of the reports and drop the @...say reports. Our goal is to stop having to maintain our reports in the @...say and ?? format only support the Visual FoxPro reports so we can limit our modification to the one format and most of our reports have already been recreated in VFP8 report generator so creating them again in the .fmt format for DOSPRINT4 would mean having to make modifications using this new tool additionally also whenever our reports change (which they do quite frequently). Thanks for pointing me to the class though it does look promising (if only we didn't already create hundreds of reports in Visual FoxPro using the report generator).
>
>
>>hi Tracy...
>>
>>I didn't program at @... say epoch, but, I had the need of printing on dot matrix printers, I've seen the asnwer is go to direct connection trough API calls, then I meet Victor Espina, he have a great tool to do this easy, he call it DosPrint, it does more than "Just Print" it's a (almost) complete report tool. Try it:
>>
>>http://victorespina.coolfreepages.com
>>
>>Hope this helps
>>>VFP8 Service Pack 1
>>
>>>There have been many threads on this issue as well as report to ascii and printing reports using ?? and ??? and @...say etc. Pardon me for creating another one!
>>
>>>We are in the process of switching all of our ??? and @...say reports over to Visual FoxPro reports still and have run into some issues with customers who use OKIDATA 320 Microline printers and OKIDATA 320 Turbos. The reports print fine but they print extremely slow because all of the Visual FoxPro reports print in graphics mode on the Okidatas. We have tried every Okidata as well as every Windows printer driver. We have also tried REPORT FORM TO ascii and there seems to be a problem with a loss of data and truncated fields. We have tried using a generic/text printer driver and it doesn't always align the fields correctly on the form. Modifying the reports for that driver is out of the question because many of our customers use the HP laserjets or GDI printers as well. Right now we have duplicate copies of the same report for different printers and it is a bear to maintain when we have so many reports. We have specific forms that are controlled by state guidelines and since our
>>software is used in all 50 states we have potentially nearly a thousand reports to eventually support. Our goal (having hundreds of reports to maintain and hundreds of customers) is to have only one copy of each report in Visual FoxPro format created using the report generator but to somehow allow it to print in draft mode on the Okidatas so that they print faster for those customers and preventing the need for maintaining duplicate copies of the same reports for different printers. Our reports tend to change on an annual basis (or more frequently) so we do not want to have to modify duplicates of all reports on a regular basis.
>>
>>>Any ideas?
>>
>>>Thanks in advance,
>>>Tracy