>Hi Nick,
>
>>Problem is I can only do this if the COM object is a VFP .exe not a .dll. This is obviously rather slow.
>

>A better approach, however, might be to have a queue of some sort (MSMQ, table, etc.) where you add a request to a report and a service/VFP exe that prints off the queue. Otherwise the web application would suspend until the report is fully submitted to the printer driver.

I agree 100%.
COM to be kept simple (simply store report parameters) and then fully powered VFP exe
(can be multiple instances or one multithreaded EXE) waiting idle and simply executing tasks from that que as they come and
then returning HTML or PDF.

I actually implemented something like this in order to make my ReportScultor reporting available from web (ASP.NET app)
and it works very fast. NET app is writing record to that que via WestWind page and then another EXE is producing RS report
which is later shown as PDF in NET app.

To expand on this;
It would be interesting to kind of round up / standardise this sort of scenario not only for reporting, but all sort of other tasks in some
hybrid VFP/NET multi app environment. NET Interface posting records (various tasks) to some que (VFP table) , while VFP exe (or group of them) which runs independantly from NET app actually watching that table and executing those tasks as they come.
and then writing back to the same que record. It could be status of some data related operation, path to PDF report, peace of HTML or whatever.
COM Object could then pick it up from the same que record and communicate info back to NET app.

Not exactly marriage of a loving couple (VFP/NET), but it could be interesting relationship to say at least {g}

Cheers :)