WaitForSingleObject stopped working

[AndyGroom]

I'm using some code to launch Word and wait until the user closes it. The code has worked fine for years but for some reason has now stopped working, I'm wondering if either Windows or Office has had some kind of update that would have affected it?

Const Synchronize = &H100000
Private Const Infinite = -1&
lRetVal = Shell(WordApp$, vbMaximizedFocus)
ShellAndHold = OpenProcess(Synchronize, False, lRetVal)
lRetVal = WaitForSingleObject(ShellAndHold, Infinite)
lRetVal = CloseHandle(ShellAndHold)

- Andy
___________________________________________________________________
If you think nobody cares you're alive, try missing a couple of mortgage payments

 

[Hypetia]

You means to say that WaitForSingleObject returns without waiting?

What values are returned by OpenProcess and WaitForSingleObject functions? And Err.LastDllError after each function call? It might be possible that OpenProcess is not returning a valid handle.

I just tested and it works fine for me. WinXP/Office 2007.

 

[AndyGroom]

Shell(WordApp$, vbMaximizedFocus) returns 16412 / last error 0
OpenProcess(Synchronize, False, lRetVal) returns 1904 / last error 0
WaitForSingleObject(ShellAndHold, Infinite) returns 0 / last error 0

These seem to be valid values as far as I can tell, but on my machine VB simply skips straight past the WaitForSingleObject.

If I try this code with Calc, Notepad, even Excel it works fine, it just seems to be Word that it doesn't work with. I'm on XP / Office 2003 SP3.

- Andy
___________________________________________________________________
If you think nobody cares you're alive, try missing a couple of mortgage payments

 

[Hypetia]

Looking at the return values and LastDllError, every function seems to be working fine without any error.

What is the path you specify for WordApp$? Is it something like this?

"C:\Program Files\Microsoft Office\Office11\WINWORD.EXE

 

[AndyGroom]

Yes, exactly that.

- Andy
___________________________________________________________________
If you think nobody cares you're alive, try missing a couple of mortgage payments

 

[strongm]

I have seen this happen when there is already an instance of Word running

 

[AndyGroom]

Yes, I thought it might have an effect on it but this still seems to happen even when Word is definitely not already running. It must be something peculiar to Word because everything else I've tried it with works fine.

Perhaps Word has some new kind of malware or antivirus protection that has affected WaitForSingleObject? I noticed that after the latest Office SP if you open a mailmerge document it now always asks you to confirm the SQL database source (although there's a registry setting to bypass this) because apparently the SQL commands can be a security hole (

http://support.microsoft.com/kb/825765).

Perhaps some other security checks at start-up are affecting WaitForSingleObject.

- Andy
___________________________________________________________________
If you think nobody cares you're alive, try missing a couple of mortgage payments

 

[strongm]

>Perhaps Word has some new kind of malware or antivirus protection that has affected WaitForSingleObject?

Trouble is that WaitForSingleObject (and specifically your code) is working fine here on XP SP3 with both Word 2003 and Word 2007 ...

However, this may actually be a timing issue related to the startup of the process. If you look through the examples of ShellAndWait or ShellAndHold or whatever in this forum you;ll find that many of us advocate the addition of the following line (or similar) just before the WaitForSingleProcess:


If ShellAndHold <> 0& Then WaitForInputIdle ShellAndHold, INFINITE


Try adding this and see if it helps

 

[AndyGroom]

Nope, no luck there.

I added a breakpoint on this line:

lRetVal = WaitForSingleObject(ShellAndHold, Infinite)

Once Word was open I stepped through the code hoping VB would stick at this line until I closed Word but it doesn't. Can I add any code at this point to validate that ShellAndHold is the correct handle for the instance of Word which actually opened and that is hasn't changed for some reason?

On the basis of your feedback I'm kind of content that this might not be an issue for most of our users, it's just unusual for something to not work on my machine, it's usually fine on mine and doesn't work on the client's machines!

- Andy
___________________________________________________________________
If you think nobody cares you're alive, try missing a couple of mortgage payments

 

[tsuji]

I would suggest adding a line just before the waitforsingleobject line to make word application loss focus, such as:
[tt] me.focus[/tt]
if me.focus make sense in that context. If the word application being in focus is absolutely desirable (as originally would with vbMaximizedFocus), add another line to give it the focus again thereafter.

The basis of this is the observation that office application, at the start of its process, would not register itself to the rot (running object table), for efficiency consideration. It would do only once it has lost its focus. I would think waitforsingleobject depends somehow on entries of the rot.

This is the relevant info discussed in the documentation.

http://support.microsoft.com/kb/238610

 

[strongm]

The Object in WaitForSingleObject has absolutely nothing to do with the similarly named Object in the Running Object Table. They are completely different things.

 

[tsuji]

ping back.

 

[tsuji]

Did I say it is the same???

 

[strongm]

It probably wont make any differenc - but you might like to try my minor reworking of the classic ShellAndWait as outlined in the ExecCmd example in thread222-1393439. This uses CreateProcess rather than Shell to launch the app, and might reveal whether there is an issue with the Shell command.

 

[AndyGroom]

My original code used CreateProcess and when it stopped working for no apparent reason I changed it to the code which I posted.

The original code that I was using turned out to be the ExecCmd code from the link above, which I've now gone back to - but alas it doesn't solve the problem.

- Andy
___________________________________________________________________
If you think nobody cares you're alive, try missing a couple of mortgage payments

 

[strongm]

Ah well, Worth a shot.

 

[strongm]

>Did I say it is the same???

No. And I didn't say that you did. You said:

> I would think waitforsingleobject depends somehow on entries of the rot

And I was simply saying that they've got nothing to do with each other.

 

[tsuji]

Language is a fabulous invention.

 

[vb5prgrmr]

As a passer by, trying not to rubberneck too much, I have to wonder.... I see the create and the shell but not the ShellExecute and as that thought passes through my mine, so does this thread...

 

[Hypetia]

I just confirmed strongm's observation that WairForSingleObject might not work if a previous instance of Word is running.

When you start first instance of Word, the PID returned by the shell function is that of the fresh instance of the Word. WaitForSingleObject works fine on the handle opened from that PID.

But as we launch following instances of Word, they are all launched in the context of the first instance, and wait function on following instances does not work. The application in the following instances, just adds a new window, with a new document in the first context and terminates.

You can verify this by comparing the PID returned by Shell function and retrieving the PID in Word by using GetCurrentProcessId in the context of Word VBA.

GetCurrentProcessId only returns the first PID and whereas each call to shell function returns a new PID which may is useless with OpenProcess/WaitForSingleObject funciton.

But you say that you cannot make it run even with the first instance of the Word. I would advise you to compare the PID returned from Shell function with the one returned by GetCurrentProcessId in Word's context. Also compare it with the PID shown in the Task Manager. It should match the PID returned from the first Shell function call.

If it does not, I suspect that there is some hidden add-on, malware or something else which is preventing Word from completely terminating and thus keeping an old reference alive. You can verify this by looking in the Task Manager, when the Word is not running.