>>>I am creating a word document from VFP data and have noticed that this process run extrememly slow on the average machine (p166) and relatively slow on fast machines (pII 400). My question is this, are there any general tips someone can give me that I may have over looked in having vfp communicate to word. Some little known or not well documented thing I need to do or failed to do that would make creating a word document slow. The process write now does the following: Get the data, open a word template, place the data into the template, then save the word doc under a new name. The document created can range from 5 to 50 pages. Any help would be appreciated. By the way, the document does get created and the process works great, but it is very slow.
>>
>>Bret,
>>Word automation is slow naturally it uses VBA :) But slow is a loose definition you know. Before I attempt to say anything could you give ie: how much it takes to complete now. Till then Application.datatoclip and preformatting what will be put in word in VFP speeds up a lot relatively ;) I mean, if possible do one InsertAfter in word rather than many.
>>Cetin
>
>Thanks for the reply Cetin. Yeah I know VBA is slow, but I never thought it would be this slow. If I am processing a say 20 page document, the user is telling me that it takes about 20 minutes to create the document on their P166 machine. On mine the document gets created in about 7 minutes (PII 400). This is creating a pretty complicated document. Reading from memo files and table data. Bolding and underlining where told. What do you mean by Application.DataToClip?

7 mins on PII 400 ? Good than it's a candidate for optimizing. It should be under 2 mins (of course depends on what should be done).
Application.Datatoclip is a fast way to transfer data via clipboard. ie:

#include "wdconstants.h" && Assumed you have this file
use home()+"samples\data\customer"
Application.DataToClip(alias(),reccount(),3) && Copy to clipboard separated with tabs
oWord = createobject("Word.application")
with oWord
  .Documents.add
  .ActiveDocument.Pagesetup.Orientation = wdOrientLandscape
  .Application.Selection.Paste
  .ActiveDocument.Content.ConvertToTable(wdSeparateByTabs)
  .visible = .t.
endwith

This would transfer customer data as a table to word. Timing is 1.8 secs on my K6-2-333, 64Mb. But wouldn't work with memo fields (ie:if employee used, employee.notes is missing). Also this adds an extra tab at the end of each record + each field are padded with spaces to its size. If you try to correct this in word simply you lose time. So do it in VFP :

Application.DataToClip(alias(),reccount(),3)
_cliptext = strtran(_cliptext,chr(9)+chr(13),chr(13))
_cliptext = strtran(_cliptext,chr(13)+chr(13),chr(13))
do while occurs(" "+chr(9),_cliptext)>0
 _cliptext = strtran(_cliptext," "+chr(9),chr(9))
enddo

While this seems a dummy way of doing it, doing it in VFP is fast (expressed as 0.5-0.6 secs for customer) and believe me doing it in word is far more than a second.
But we need memo transfer ! OK then we have ODBC (do we really by new MDAC?). Slightly change the code to read :

oWord = createobject("Word.application")
with oWord
  .Documents.add
  .ActiveDocument.Pagesetup.Orientation = wdOrientLandscape
  .Application.Selection.InsertDatabase(, , 1, ;
	lcConnection, cSQLStatement, ,,,,, cDataSource,,,1))
  .visible = .t.
endwith

lcConnection is ODBC connect string like in VFP SQLSTRINGCONNECT. cDataSource is the table itself. First 1 is True for link (faster) and last is .t. for includefields. Well this works where you can really supply ODBC info to word and if it doesn't complain "no installable ISAM driver found" or alike ODBC error (I'm not sure it stands for OpenDatabaseConnectivity:).
What then. How would I be sure this would work on another site or when someone starts to use Word95 (century 20:) ? Or would this allow me to do it when I have a form that keeps the table open ? To my experience no unless to let word to use it exclusively by any means (I'm not also sure what Exclusive=No in connection string means). My little solution to this question is nonODBC native fox transfer :) Weapons are _cliptext and .paste. Problem is how large strings could be copied to clipboard (experimental). Very roughyly outline of code would be :

#define TABULATE chr(9)
#define CR chr(13)
_cliptext = ""
scan
for ix = 1 to fcount()
 _cliptext = _cliptext + ;
   iif(empty(_cliptext),"",TABULATE)+;
      ConvertToChar(eval(field(ix)))   
endfor
 _cliptext = _cliptext + CR
endscan

Then we would paste to word and converttotable as before :) Being honest I wouldn't do it like this _cliptext = _cliptext + ... way but to gain more speed first write to a temp file with lowlevel function then just open or insertfile(Filename) that file in word (maybe with link set to .t. - to insert at a INCLUDETEXT field position). If we chose to link method our template could predefine bold, color etc formatting beforehand for the insertion.
Another way is to have a predefined template for mailmerging only selected recs to doc.
Well depends on real implementation. Even using Excel as intermediate an option.
Cetin