Thanks, Jim.

The bottom margin issue is one I am still working on a bit. Oddly enough, when you print the Word Doc, it looks just like the Fox report but it doesn't on-screen. My advice is to go into the source code and play around with the value of the Word PageSetup BottomMargin property. This is one of the reasons I included the source code in the file.

As to numbers, I suspect that VFP does "best guess" formatting based on the field structure when printing a numeric field with no explicit Format. I tried emulating this in early versions of FRX2Word but it slowed things down too much and sometimes made things worse. The simple solution is to make sure you have a Format for all numerics in the report form; ie, "9,999.99". This *is* respected 100% by FRX2Word.

As to the speed issue, it's 99.9% the fault of Word and the speed of automation. The complex setup that goes on before anything significant is sent to Word takes from 1 to 3 seconds on my 266MHz P2 with 64MB. The rest is writing objects out to Word and having Word respond. A single given item, if you look at a coverage log (use the CoverLog property to create one), can take 1 second to write to Word(!). Multiply that by x rows and x items per row and you can see where speed is a problem.

What I am thinking of (mind you, *thinking*), is to readdress this issue when we get an OLE DB provider for VFP data by rewriting Frx2Word as a Word macro or COM add-in called internally in Word to reduce the automation calls. This may boost the speed somewhat. I dunno.

>Just for the record, I went to my first site yesterday and made the change from the CURDIR() call to the default SaveFolder(). It worked fine. I can also confirm the lengthy processing time. My second report has 4 pages of 125 rows from one table. It has grid and column lines. It to at least 15 minutes to run. I have not scrutinized it, but the two problems I noticed were:
>--page footers (summary band) chopped in half i.e. too low on the page.
>--ROUND() calculations done on the form's details band were ignored, causing the numbers to be long and hence to wrap. E.g.: 234 became
>234.0
> 0000
>Still love it though!
>
>Jim