>>I've got some code that determines whether or not Word is open...unfortunately, I can't get to it until later today. It uses the FindWindow Win32 API function that finds the first top level window based on class name or window name. If Word is still open, you can use GetObject() to attach to it and shut it down.
>>

I've extracted the pertinent code:

* Determine if the Server App is already open & running
*------------------------------------------------------
LOCAL ClassName, WHandle

* Declare the function to find the window.
* Always pass the CLASS NAME, because the window
* name is unreliable unless you know the state
* (minimized, maximized, or restored). Pass a 0
* for the window name.
*------------------------------------------------
DECLARE INTEGER FindWindow IN User32.DLL ;
        STRING, INTEGER

* Set up the string for the Class Name
*--------------------------------------
ClassName = "OpusApp"
WHandle = FindWindow(m.ClassName, 0)

* If the window handle is 0, it's not running.
* If it's > 0, it is...
*----------------------------------------------
m.RetVal = (m.WHandle > 0)

OK, this tells you if Word is running. It only returns the first instance, so you can't be sure if you're getting an "orphaned" instance or if the user has opened his biography that he's been working on for four years without ever saving...I've never figured out how to get any instance other than the first, other than knowing the titles. If anyone can help here, jump on in!!!

>I already have another reason for needing it: I've noticed another problem. If I go through the following automated program sequence.
>
>open word
>open worddoc
>edit worddoc
>quit word while saving changes
>copy file worddoc to server:worddoc
>erase worddoc
>
>The erase causes a 'file access denied' error...apparently because word hasn't really shut down and released it yet! (Surely the copy file command doesn't return until it has finished??!!) If I use the debugger to halt at the erase line and then step throug it, it works every time.

Try adding a DOEVENTS after quit, and another after the copy. I think VFP simply fires off each line and doesn't wait for Windows events to process before proceeding. DOEVENTS will likely solve that.

I've found that when I do development, I have far more orphaned instances of Word (or any of the other servers) hanging around than my users do. I tend to escape (or crash) out of programs, leaving hanging instances--and it's surprising how many times you don't remember doing it!

Another way to prevent seemingly orphaned instances: be sure that EVERY object reference is removed. For example, you'll likely have references to oWord, oDoc, oRange, and perhaps several others. If you try to shut down Word with open references, it may not shut down (I know this is true of Excel, and I can't remember if Word is similarly affected). The same holds true of VFP forms -- you have to release all of the references before you can release/destroy the form. So be sure you go through and set all your objects to .NULL. just after you issue the Quit method.

Checking your object references and adding DOEVENTS may reduce the need to use FindWindow to check on things -- assuming that this is not an app that runs 24x7.

Hope this helps,

- della Martin