Word Automation 1

[MgtHargreaves]

I am hoping that some-one else has come across a problem we have encountered recently. We have a 'vertical market' product used by over 100 customers, and now have a problem with 3 of these.

If a Word document is open (via Word) on the system, and then the software opens another Word document using automation, everything is OK until the user closes the document created by the software. A message saying that the normal.dotm is in use by another user is displayed. The code in use is as follows :

m.cfile = "file name"
oWord = CREATEOBJECT("Word.Application")
oWord.Documents.Add (m.cfile)
oWord.Visible = .T.
oWord.Application.Activate
RELEASE oWord

By changing the code to

m.nAns = ShellExecute(0,"open",cFile,"","",1)

the problem goes away.

We have around 45 situations in the software using Word automation, and the majority are not as simple as this case, so the solution above will not be sufficient.

All three machines are running Word 2007, 2 are Windows 8 and one is XP.

Any thoughts gratefully received.

Margaret Hargreaves

 

[Mike Lewis]

Hello Margaret,

First, you're right that switching to ShellExecute() is not the right solution. ShellExecute() is quite different from Automation. It works fine if you simply want to open a document and then leave all interaction to the user. It's not so good if you want to control the documentation in any way from within your program.

So you need to stay with Automation. Before opening the document, you need to check to see if there is an existing Word session in progress. You do that via GETOBJECT() rather than CREATEOBJECT().

The following is a generic routine that will do the above. It will get a reference to either an existing session or to a new one. Either way, the end product is a valid object reference, which the routine stores in THISFORM.oWord. You will need to modify it if you want to store the reference somewhere else.

* Try to instantiate Word. If successful, return .T. 

LOCAL loWord, llError, llJunk

IF NOT ISNULL(thisform.oWord)
  * Word has been instantiated ...
  TRY
    llJunk = thisform.oWord.Visible
  CATCH
    * ... but an attempt to access its PEMs has failed;
    * this indicates that the user closed Word interactively
    * since it was last instantiated; the solution is to
    * clear out the object reference so that we can instantiate
    * it again.
    thisform.oWord = NULL
  ENDTRY
ENDIF 
	
IF ISNULL(thisform.oWord)
  * Word not yet instantiated (in this form). So first try to get
  * a reference to an existing Word session
	
  TRY
    llError = .f.
    loWord = GETOBJECT(,"word.application")
  CATCH
        llError = .t.
  ENDTRY
	
  IF llError
    * That didn't work, so try for a reference to an existing Word session
    TRY
       llError = .f.
       loWord = CREATEOBJECT("word.application")
    CATCH
       llError = .t.
    ENDTRY
		
    IF llError
        * That didn't work either, so jump out
        RETURN .F.
    ENDIF 
		
  ENDIF 

  * Successfully opened Word. Store the object ref.
  thisform.oWord = loWord
  RETURN .t.
	
ENDIF

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

Mike's suggestion is right on.

Before opening the document, you need to check to see if there is an existing Word session in progress.

To manually (visually) check this, when this occurs open your Task Manager and look to see if you find Word.exe listed multiple times among the tasks.
Sometimes, you will find Word (or Excel or others) open in the Task Manager even when they do not appear on-screen.

I have found this to be the case numerous times.

We have a 'vertical market' product
If this is an off-the-shelf application then you would need to contact the vendor/developer to get the additional 'fault-tolerant' code added.

Also you have not indicated the version of VFP you are using (or your application is using).
The TRY/CATCH code that Mike has shown works well IF you are using VFP 8 or 9, but not earlier.
Again, if this is an off-the-shelf application that too would need to be addressed by the vendor/developer.

Good Luck,
JRB-Bldr

 

[MgtHargreaves]

Mike

Thanks very much - on initial tests this does seem to fix the problem. It is just so weird that we have not had this problem in all the years we have been using automation.

JRB-Bldr - We are the developers of the software using VFP9, and have been using automation for years without this problem on all Windows platforms, and all versions of Word.

Margaret

 

[Mike Lewis]

Glad to hear it worked, Margaret.

Regarding JRB's point:

To manually (visually) check this, when this occurs open your Task Manager and look to see if you find Word.exe listed multiple times among the tasks.
Sometimes, you will find Word (or Excel or others) open in the Task Manager even when they do not appear on-screen.

This is a good point. It's something that happens a lot during testing. Often, a test run will fail, and leave an invisible instance of the application (Word, or whatever) running in the background. When I'm developing this kind of Automation code, I like to leave the Task Manager open, with the list of processes in alphabetical order, so I can easily pick out Winword or whatever and kill it if necessary.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

> It is just so weird that we have not had this problem in all the years we have been using automation.
Indeed. I haven't come across this in Win Vista and Win7 with Word 2010, even though I also always CREATEOBJECT("Word.Application").

I know the GetObject approach, too, I have also recommended it in case somebody wants to let his document be opened or generated in a current word session, but in other cases it's even better to do something in a separate word session. Even just to not crash the current session if something fails, but only crash the new word process.

I's say there could be some setting about formats and a normal.dotx playing a role here.

I would ask users experiencing this to open the task manager and see how many winword.exe processes are running. In theory only two, theirs and yours, but if there is a third or more there seems to be a problem.

Bye, Olaf.

 

[MgtHargreaves]

Thanks Olaf

My gut feel is that it is something to do with a setting in Word which is different on these few machines, but up to now I haven't been able to find it.
I checked task manager, and only 2 winword.exe processes were running. Interestingly, having replied 'No' to the original 'normal.dotm in use by another user, do you wish to overwrite' message, it takes 2 more dialog boxes before that copy of Word closes. The second copy of Word can then be closed normally. But when shutting down the machine, Windows 8 notifies us that a Word APP is still running - even though there is no evidence in the Task Manager, so we have to 'force' a shutdown.

Mike's suggestion of using GETOBJECT gets round the issue for now, until we can find the real cause of the problem.

Margaret

 

[Olaf Doschke]

If you run in the situation WMI might give you more clues than the Task Manager:

LOCAL loLocator, loWMI, loProcesses, loProcess
loLocator 	= CREATEOBJECT('WBEMScripting.SWBEMLocator')
loWMI		= loLocator.ConnectServer() 
loWMI.Security_.ImpersonationLevel = 3  		&& Impersonate
 
loProcesses	= loWMI.ExecQuery([SELECT * FROM Win32_Process WHERE Name = 'WINWORD.EXE'])
IF loProcesses.Count > 0
	FOR EACH loProcess in loProcesses
	   ? loProcess.CommandLine
           ? loProcess.ProcessID
           ? loProcess.ParentProcessID
           ?
	ENDFOR
ENDIF

AFAIK, the parent process of Winword.exe started by automation is the process id of the DcomLaunch service, the commandline has the /Automation parameter and so you can see which process is started by you and which manually. Maybe you'll also see the third. It could be a process from another user logged in at the system, too. You don't see these processes, unless you click on the button "Processes of all users" (or similar) in the footer of the process tab.

Bye, Olaf.

 

[MgtHargreaves]

Thanks Olaf, I will have a look at that.

I have just discovered something else which might give a bit of a clue.

Using CREATEOBJECT to open Word. If the software controls the opening of Word, opening, populating, printing and then closing the document - typically for invoices - then the problem does not happen. However, if the software just opens Word, populates the document and leaves the document on the screen for the user to manipulate and close, we get the error.

Margaret

 

[Mike Lewis]

Margaret,

You said:

My gut feel is that it is something to do with a setting in Word which is different on these few machines, but up to now I haven't been able to find it.

I wonder if the "Prompt to save Normal template" setting might affect this (it's on the Save tab in the Options dialogue in my version, but that might vary in other versions).

Just a guess.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[MgtHargreaves]

I did check that Mike, and the setting is the same on machines which create the error as machines which don't create the error.

Margaret

 

[MgtHargreaves]

I have an update on this.

It appears that our customer was also having the same problem when she opened Word documents directly from File Explorer. Having got very frustrated, she contacted Microsoft, paid them £65, and they logged onto her machine and seemed to have fixed the problem. Apparently, there is an occasional incompatibility issue between Word 2007 and Windows 8. Unfortunately, whilst Microsoft were logged onto her machine, our customer couldn't see what they were doing (as the screen was black), so we are none the wiser as to the cause !!

Margaret

 

[Mike Lewis]

Thanks for the update, Margaret. Pity Microsoft didn't give her more information, especially after she forked out £65, but at least they solved it for her.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads