Thanks for your reply.

We also contacted Doug Hennig regarding this and although he acknowledges a slow down, I don't think he is using a similar environment. He questioned whether .4 seconds (in 80) was significant compared to 2.1 seconds (in 90). Remember, our report is only 3 pages long and we're seeing this kind of difference. We decided to do a realworld test. Read on.

We did remove the printer environment as you suggested. And we did reverse the order of running 90 versus 80, but all that really did was make 80 as slow as 90. Not an acceptable solution at all. It appears that running 90 first actually has a negative effect when switching back to 80. I just did a fresh test and my 80 runs at .8 seconds versus 2.594 seconds for 90. I did run 90 first as you suggested. I'm running this on a IBM Thinkpad with a 1.8 ghz. processor that is hooked up to a docking station and an HP4250n (35 pages per minute) printer.

Now for our realworld example, we have an application that we use to track our users. It also prints upgrade order blanks at the end of the year when we issue new updates for our software. For testing purposes, we printed 250 upgrade order blanks. It took over 284.469 seconds to dump this to the print queue. This is the time that the progress bar that VFP generates is on the screen. If you look in the print queue, the printjob is 1.66 gig. No wonder it takes so long.

Using 80 report behavior, it took .901 seconds to dump to the print queue and the file size was 3.21 MB.

This doesn't begin to address the problem of how slowly the printer can process the printjob. In 80 the pages flow out of the printer without any delay at all. In 90, there is perhaps a 20-30 second delay between pages.

I can't believe that with all the hype over the improvements in the report writer that no one mentioned this horrific slowdown. This is NOT what VFP built its reputation on and will certainly detract from the benefits the 90 behavior provides.

I'm going to post a link to the zip file on our website for others to download and test.

>Hi John,
>
>I ran the code that you emailed me and here's what I found. When running your sample, yes, it ran slower with the 80 setting than it did the 90 setting. However, if you swap order of your test and do the 90 first, the times vary greatly. The first time, the 90 runs faster. The second and subsequent times, the 90 runs a little slower, but not very significant.
>
>Another thing I noticed is that your report has the printer information saved. This can cause speed issues if the printer that is saved is not available when you print the report. That's because it tries to find that printer first. I have also seen major speed issues along these lines when on a wireless connection because it tries to search the connection for a printer and that can slow it down.
>
>Cathy
>
>
>
>>Hopefully, it's me, but printing the same report using 90 report behavior with the default reportlistener is dramatically SLOWER than printing the same report using 80 report behavior. Anyone offer any help or suggestions here.
>>
>>Here is the code differences for 80 and 90 ...
>>
>> WAIT WINDOW " PRESS ANY KEY TO PRINT USING 80 BEHAVIOR "
>> REPORT FORM (lcFRX) TO PRINTER
>>
>>
>> WAIT WINDOW " PRESS ANY KEY TO PRINT USING 90 BEHAVIOR "
>> REPORT FORM (lcFRX) OBJECT TYPE 0
>>
>>The 90 version prints 10 times slower with a noticeable pause between each page. Total unusable.