>>I don't understand, that file is there during compilation,
>I'm not worried about compiling. The question was about the hard-coded path to the MSWord.olb file at the time of instantiation of the eventhandler. (I can't test to see if that produces an error because I don't have another Word version available.) In the client's environment users may have any version of Word from 8 upward. Some may have more than one version installed, either as part of Office or as a stand-alone application.
>
>Thank you for the expanded code sample. I'll work with it for a while and let you know how it goes. Perhaps part of the problem is the way the code is being called. There is a class that handles Word automation. It works perfectly for the 16 out of 18 documents that are produced entirely without user intervention. For the 2 documents that allow user editing, I would like to run this code to allow the user to edit. When the user is done editing, control should pass to the next line in the automation class--where the document will be saved (if allowed) and/or printed to PDF or to Printer, depending upon the situation. The problem is that I want Word to remain open so that processing can continue. Sounds easy enough but so far, hasn't worked well.
>
>Here is my update after testing the code you provided: I still do not see a way for VFP's automation process to regain control of the open instance of Word. The ONLY way VFP regains control seems to be when Word is closed. Has anyone ever accomplished this?

Lynda,
Then do not call Quit() (VFP already has control - check those messages printed in VFP window. Maybe you mean window.activate).
Cetin