"Karl E. Peterson" <k***@mvps.org> wrote in message
news:eyzqOEP1FHA.4064@TK2MSFTNGP09.phx.gbl...
> Tony Spratt wrote:
>> I'm in a situation where there may be many (or no) instances of Word
>> running on a PC.
>
> Do you _really_ think so?  Take a look at the processes tab in Task
> Manager, if you
> wonder why I ask.
>
>> I need to find one in particular, if it exists, and
>> manipulate it. What I would ideally like to do is iterate through the
>> list using GetObject(), but this doesn't work: GetObject() always
>> returns the first instance rather than going through them one at a
>> time.
>>
>> Is there an equivalent function that returns an array or collection of
>> objects? I've searched MSDN and Google but can't find anything.
>
> Take the "first instance" that GetObject returns.  Then iterate the
> Documents
> collection, looking for what it is you're after.

> > Tony Spratt wrote:
> >> I'm in a situation where there may be many (or no) instances of Word
> >> running on a PC.
> >
> > Do you _really_ think so?  Take a look at the processes tab in Task
> > Manager, if you
> > wonder why I ask.
> >
> >> I need to find one in particular, if it exists, and
> >> manipulate it. What I would ideally like to do is iterate through the
> >> list using GetObject(), but this doesn't work: GetObject() always
> >> returns the first instance rather than going through them one at a
> >> time.
> >>
> >> Is there an equivalent function that returns an array or collection of
> >> objects? I've searched MSDN and Google but can't find anything.
> >
> > Take the "first instance" that GetObject returns.  Then iterate the
> > Documents
> > collection, looking for what it is you're after.
>
>
> IOW....what Karl is saying is that there's ever only one instance of Word.
> You might see multiple taskbar buttons for each document that's open, but
> there's still only one instance of Word.
>
> For example, copy and paste this code into Form1 of a new, standard EXE
> project:
>
> -----BEGIN CODE
> Private Sub Form_Load()
>
>     Dim oWordApp As Object
>
>     Set oWordApp = GetObject(, "Word.Application")
>
>     Debug.Print "Number of open documents: " & oWordApp.Documents.Count
>
>
> End Sub
> -----END CODE
>
> BEFORE you run this code in VB, start Word and open several documents (new
> or existing, it doesn't matter).  You can start Word from a shortcut or by
> double-clicking winword.exe, multiple times either way. Each time you open
a
> new document, the "document number" increments.  That should tell you
> something.
>
> --
> Mike
> Microsoft MVP Visual Basic
>
>

"Tony Spratt" <tony_spr***@hotmail.com> wrote in message
news:%236jd0OV1FHA.1028@TK2MSFTNGP12.phx.gbl...
> Mike, Karl,
>
> What a klutz! Just because activating (or .Show-ing) brought the wrong
thing
> up, I got the wrong end of the stick. D'oh!
>
> Anyway, thanks to the pair of you for setting me straight.
>
> Just out of curiosity, is there actually a way to iterate through object
> instances where there is more than one running? Or do you have to go down
a
> more complex road and browse processes and the like?
>
> Cheers,
>
> Tony.
>
>
> > > Tony Spratt wrote:
> > >> I'm in a situation where there may be many (or no) instances of Word
> > >> running on a PC.
> > >
> > > Do you _really_ think so?  Take a look at the processes tab in Task
> > > Manager, if you
> > > wonder why I ask.
> > >
> > >> I need to find one in particular, if it exists, and
> > >> manipulate it. What I would ideally like to do is iterate through the
> > >> list using GetObject(), but this doesn't work: GetObject() always
> > >> returns the first instance rather than going through them one at a
> > >> time.
> > >>
> > >> Is there an equivalent function that returns an array or collection
of
> > >> objects? I've searched MSDN and Google but can't find anything.
> > >
> > > Take the "first instance" that GetObject returns.  Then iterate the
> > > Documents
> > > collection, looking for what it is you're after.
> >
> >
> > IOW....what Karl is saying is that there's ever only one instance of
Word.
> > You might see multiple taskbar buttons for each document that's open,
but
> > there's still only one instance of Word.
> >
> > For example, copy and paste this code into Form1 of a new, standard EXE
> > project:
> >
> > -----BEGIN CODE
> > Private Sub Form_Load()
> >
> >     Dim oWordApp As Object
> >
> >     Set oWordApp = GetObject(, "Word.Application")
> >
> >     Debug.Print "Number of open documents: " & oWordApp.Documents.Count
> >
> >
> > End Sub
> > -----END CODE
> >
> > BEFORE you run this code in VB, start Word and open several documents
(new
> > or existing, it doesn't matter).  You can start Word from a shortcut or
by
> > double-clicking winword.exe, multiple times either way. Each time you
open
> a
> > new document, the "document number" increments.  That should tell you
> > something.
> >
> > --
> > Mike
> > Microsoft MVP Visual Basic
> >

> "a way to iterate through object instances where there is more than one
> running"
>
> Not really. At least not from your program, or rather not in the simple
> sense you likely mean. You can ask for a reference to an Automation
> Instance, but which one you get is purely up to Windows. (Or in the case
of
> Word - which 'window'). So alas you can't just open up a collection and
pick
> one.
>
> In order to communicate with most processes, you have to go a more exotic
> route - (FindWindow, SendMessage, ...)
>
> However, with Office Automation, you can often ask to speak to a specific
> document, so it really depends on what you want to do.
>
> -ralph

"Tony Spratt" <tony_spr***@hotmail.com> wrote in message
news:%237bv08Y1FHA.2704@TK2MSFTNGP10.phx.gbl...
> <snip>
>
> > "a way to iterate through object instances where there is more than one
> > running"
> >
> > Not really. At least not from your program, or rather not in the simple
> > sense you likely mean. You can ask for a reference to an Automation
> > Instance, but which one you get is purely up to Windows. (Or in the case
> of
> > Word - which 'window'). So alas you can't just open up a collection and
> pick
> > one.
> >
> > In order to communicate with most processes, you have to go a more
exotic
> > route - (FindWindow, SendMessage, ...)
> >
> > However, with Office Automation, you can often ask to speak to a
specific
> > document, so it really depends on what you want to do.
> >
> > -ralph
>
> Ralph,
>
> Thanks for the reply. The problem is that there are several processes
> (mainly DLLs) which create Word documents on demand. The formatting of the
> document (insertion of text, etc.) is done with the document window not
> visible. Sometimes, kicking off a session hangs. We suspect that what's
> happening is something along the lines of Word trying to pop up a dialog
box
> for some reason, resulting in processing halting. The trouble is, we can't
> see what's going on.
>
> No matter how many documents are currently open in this way,
> objWordApp.Documents.Count always returns 1 *when the fault has occurred*.
> Looking at the task manager shows several entries for winword under
> "Processes" but nothing at all under "Applications".
>
> In order to find out what's happening, we would really like to make all
> document windows visible from a separate application so we could at least
> see what the problem is. Unfortunately, we can't do this via a window
handle
> (we can track the handle down by looking for processes and working from
> there, then send the message but it doesn't have any effect).
>
> It looks like we may have to rethink the whole way we're doing things.
> Although that may not be an acceptable answer, thinking about it.
>
> If we get no further, I'll separate a sample of the document generation
code
> so you can see what I mean.
>

"Tony Spratt" <tony_spr***@hotmail.com> wrote in message
news:ucqq6Li1FHA.464@TK2MSFTNGP15.phx.gbl...
> > Hopefully someone else will come along with a better response.
> >
> > I seem to remember some tools or utilities in the Office Developers Kit
> that
> > addressed these kinds of issues. Now whether the toys were actually
> included
> > or some bit of third party stuff I collected I can't remember. However,
I
> > heartily recommend if you are not using the Developers Kit to order it
if
> > you are doing any serious work with Office Automation.
> >
> > In general I have found that when dealing with Automation, taking the
> > approach that you will somehow "own" the application and "you will do as
I
> > say", quickly turns into an exercise of 'cat-herding'. <g>
>
> Tell me about it :-(
>
> Starting from scratch would have been the best idea, long before we got to
> this stage. Unfortunately, there's never the time or the money to do the
> right thing, but plenty of time and money to scream "get this crap fixed!"
> at us later on...
>