Detect Word running from AutoExec without using Task Object

[Julie]

Word 2000, Windows XP

Does anyone know how to detect multiple instances of Word, from Word VBA
Autoexec macro, without using the Tasks collection. I am finding tasks
collection to be unreliable in that sometimes evaluation of the collection
indicates multiple Word tasks even when there is only a single task running.

One thing that causes the problem is installation of support for Asian
Languages. After install, autoexec procedure detects anywhere from 2-6 Word
tasks, yet once Autoexec is finished and Word is up, running the same code
reports only a single instance.

Installation of support for Asian Languages is not the only cause to the
problem. - I have previously encountered the problem,and resolved it by
having the workstations rebuilt.

Thanks!

 

[Word Heretic]

G'day "Julie" <[email protected]>,

Use Application.Ontime (VBE help is quite good on this command) to
delay execution of your test code. Essentially you wrap your test code
into a sub of its own, and call it from the OnTime command a few
seconds later. This gives Word a chance to finish rationalising its
environment before you test it.

Steve Hudson - Word Heretic
Want a hyperlinked index? S/W R&D? See WordHeretic.com

steve from wordheretic.com (Email replies require payment)


Julie reckoned:

 

[Julie]

Thanks Steve.

I will try that. I am sceptical about whether Ontime will help here because
the function that tests for multiple sessions returns a value to AutoExec to
indicate whether to proceed to carry out steps that require there be only a
single session. I assume that a macro launched with OnTime won't run until
all macro execution ends. Correct? If so, I will need to find another way
to detect word running.

I seem to recall reading once about a registry key that can be checked to
determine if Word is running. Do you know anything about that?

Thanks,
Julie

 

[Julie]

I'm still looking for a resolution to this. On-time method to suspend the
test works, but it doesn't run until after the AutoExec macro finishes.
Unfortunately, my AutoExec macro must test for Word running and if so, exit
early without processing its tasks because the tasks cannot run while the
global templates are open.

Does anyone know how to test for multiple sessions of Word from AutoExec
without using the tasks collection?

Thanks,
Julie

 

[Word Heretic]

G'day "Julie" <[email protected]>,

Move EVERYTHING in the autoexec AFTER the OnTime. If Word is open, do
a ActiveDocument.Close False and an Application.Quit. Then nothing
will until your tests have said ok.


Steve Hudson - Word Heretic
Want a hyperlinked index? S/W R&D? See WordHeretic.com

steve from wordheretic.com (Email replies require payment)


Julie reckoned:

 

[Julie]

Steve,

Thanks for waking me up. I was so busy looking for a difficult solution
that I could not see the simple one staring me right in the face! Time for
a holiday here.

Your solution works like a charm, as I am sure you expected it to!

Thanks!
Julie

 

[Julie]

Steve,

Actually, I am still sleeping here ....


I renamed the autoexec to "AutoexecPro" and changed the Autoexec to include
only the OnTime method to run Procedure "AutoExecPro" and nothing else.
That, of course, solves my problem with the task object, but it creates
another problem.

That is, the On Time delay provides an opportunity for the global templates
in the startup folder to load before the meat of the "AutoExecPro" runs.
One of the processes that happens from AutoExec is to update any global
templates with newer versions from the network, so those files cannot be
open until the startup process finishes. I was expecting this problem but
forgot about it this morning when I enthusiastically tried out your
solution.

I am now back at square one again. I have been sifting through threads
about use of Windows API FindWindow function for this purpose but am not a
Windows programmer so am having difficulty following them. Is there any
hope for a resolution using the FindWindow Function? I was thinking that If
I could use FindWindow to find the handle for the first open Word session,
then get the handle for the current session and compare the two, that may
work to solve my problem, but I don't know how to make that happen.

I am not sure why you suggest the activedocument.close and application.quit.
The documents cound is zero when the autoexec macro starts. Am I missing
something?

Thanks,
Julie

 

[Pete Bennett]

Julie,

This is the code that I use in my global autoexec. It does use the tasks
collection, but reconciles it against the number of windows in the current
Word session. If they mismatch then there's more than one copy of Word
running....

Function gCheckOtherWordInstances()
Dim aTask As Task
Dim lngDocWindowCount As Long
Dim lngDocCount As Long
lngDocCount = 0
lngDocWindowCount = 0
lngDocCount = Application.Documents.Count
For Each aTask In Tasks
If StrComp(Right$(aTask.Name, 14), "microsoft word", vbTextCompare) = 0
Then
lngDocWindowCount = lngDocWindowCount + 1
End If
Next aTask

' Word open, no docs open
If lngDocWindowCount = 1 And lngDocCount = 0 Then
Exit Function
End If

If lngDocCount <> lngDocWindowCount Then
MsgBox "There is already a copy of Word running." & vbCr & vbCr & "This
copy will now terminate.", vbCritical
Application.Quit
End If
End Function

 

[Julie]

Thanks Pete,

I tried out your code and find what I was expecting - like my code for
detecting multiple sessions by evaluating Tasks, any code that evaluates the
tasks collection to find multiple sessions of Word doesn't work as expected
when running from Normal.dot Autoexec (with support for Asian languages
installed) because up until the time Normal.dot AutoExec finishes
completely, the tasks collection reports multiple tasks even if multiple
Word tasks are NOT running. Further more, I find that the number of tasks
reported varies - sometimes 6, sometimes 11, sometimes a different number.
Once Normal.dot Autoexec finishes, the tasks collection shows only a single
task. Unfortunately for me, I must make the test in the AutoExec so that I
can update (if necessary) the global templates before they load.

Thus, if I run your code with only a single instance of Word running, the
test for multiple sessions is true, and Word shuts down.

Any more ideas?

Thanks!
Julie

 

[Word Heretic]

G'day "Julie" <[email protected]>,

The doc count is zero until the AutoExecs have all finished, whereupon
Word loads a Blank Document. This is why UserForms cant display etc
until after Word loads.

I think we have to go to the time-honoured solution of semaphore
files.

Concept:

Your "must know the state of" globals each open a semphore file, eg

C:\MySemaphores\SomeTemplate.txt

(For this to work you must use FreeFile for every file open op!)

They dont close this semaphore (Close #FileHandle) until exit.

So, when a global starts, it attempts to delete its semaphore (ignore
fails) then if the file still exists - Len(Dir(FullFilename))>0 - the
global MUST be open elsewhere and you can fail gracefully.


Steve Hudson - Word Heretic
Want a hyperlinked index? S/W R&D? See WordHeretic.com

steve from wordheretic.com (Email replies require payment)


Julie reckoned:

 

[Julie]

Thanks Steve,

I had been thinking of a solution along those lines, but am not sure how I
will deal with the problems that (1) if the last session of Word crashed,
the state of semaphores may not be as expected when Word Starts, and (2) if
Word was launched by opening a document from the Browser, the autoexec
procedures don't run, yet the global templates load.

If you think that semaphore files are workable considering the above, please
advise and I will do some hacking to work it out. Tying anything new to
document opening event is not practical because I already have a very busy
document opening procedure and am afraid to add anything that may be the
straw that breaks the camel's back.

Thanks very much,
Julie

 

[Word Heretic]

G'day "Julie" <[email protected]>,

We deal with first problem by attempting to delete em first. If they
are old crash remnants, they aren't locked and can be deleted.

The second problem is tougher - does any event get triggered inside of
Word you can use for an entry point? You can also set semaphores
manually on all your UI entry points. Eg, everything publicly
addressable from MyGlobal sets and locks the MyGlobal semaphore file.

Maybe the better answer is then: Why the heck are you modifying global
templates? Modify some settings file and have the globals read from
the settings. Problem solved, get on with life


Steve Hudson - Word Heretic
Want a hyperlinked index? S/W R&D? See WordHeretic.com

steve from wordheretic.com (Email replies require payment)


Julie reckoned:

 

[Julie]

Hi Steve,

Re second problem - Word launched by opening a document from the Browser,
there are other events (other than startup) that could be used as entry
points (new, open, close, close), but I was hoping to avoid using them for
this purpose to avoid the complication. There are many factors in the
environment that may render use of semaphores unreliable for the purpose at
hand, including multiple offices scattered over three continents, with
different operating systems and different integrated third party apps,
different third party document automation application (some of which
temporarily disable auto procedures), different languages, and so on .
There are so many variables at play that I am sceptical that it is possible
to anticipate everything that must be anticipated for this solution to work
reliably.

I too, would like to get on with life and never edit the global templates!
As to changing global them, it doesn't happen all that often, but it does
happen because of changing requirements - upgrade or addition of an
integrated application, change/add requests from users, and other factors
including changes like the one under discussion here!.

Certainly, I could work around my problem using a network batch for updating
the local drive Word files but that is not preferred because to do so we
would lose much flexibility that we have with the VBA-driven method, and
would generate more network traffic than is now the case. All things
considered, my take is that changing the updates process to use a batch
driven copy from login may be the best of all of the evils. The team
members who are responsible for maintaining the Word environment at each
office will likely not agree with that.

As soon as time permits, I will rough out your idea of using semaphores and
see how it looks, and will also continue to look for a simple workaround.
In the meantime, the Asian Language support was installed only on a
dedicated workstation, and that is disruptive for the uses who require it.

Thank you for your interest and help with this problem,

Regards,

Julie