Can't "Quick View" second instance of System.Diagnostics.Process object

[gizmo]

I have a requirement to initiate more than one instance of an
application using the filenames. (the example below will start two
instances of MS Word).

My problem is that I need to kill each instance individually, but this
does not appear possible using the Process object. When I run the
example below the process object "p" can be viewed using Quick Watch
however process object p2 is displayed as undefined, with the added
affect of not being able to kill instance p2.

-Code----------------------------------------------
ProcessStartInfo startInfo = new ProcessStartInfo("a.doc");
startInfo.WindowStyle = ProcessWindowStyle.Minimized;
Process p = Process.Start(startInfo);
......
ProcessStartInfo startInfo2 = new ProcessStartInfo("b.doc");
startInfo2.WindowStyle = ProcessWindowStyle.Minimized;
Process p2 = Process.Start(startInfo2);
....
p.Kill();
....
p2.Kill();
-End Code----------------------------------------------


Does anyone have an explanation for this?
Is there another way of doing it?

Regards
Gavin

 

[Dave]

Is Word opening b.doc using the same process as the first? That would explain it.

 

[gizmo]

Thanks for your response Dave. I tested it using a text document
opening it in notepad and it works as I would have hoped, so you
appear to be correct in that it is opening Word in the same process.

That explains the problem a little further, however my problem still
remains...I need to be able to kill off one of the word documents
without killing off the other. Any ideas?

Thanks
Gavin

 

[Dave]

Yep

Using Word automation you can access the opened documents and do what you will with them. There are plenty resources out there
(just search MSDN or groups.google.com) about automating Office applications.

You need to reference an Interop wrapped Word assembly. You can do this by opening the project references dialog in VS.NET, hitting
the COM tab and browsing for Microsoft Word. I don't believe Office supplies any Primary Interop assembly for Word at this time,
but if I'm wrong it would be under the .NET tab, or in a folder somewhere in the office heirarchy of folders. For now, just use COM
tab and select Word as I suggested. If it's not in the list, simply browse to the executable and add it. VS.NET will use a tool to
wrap the assembly for you.

Here are examples of using automation in C#:

using Word;
...
Word.Application app =
Activator.CreateInstance(Type.GetTypeFromProgID("Word.Application", false)) as Word.Application;

This code places the instance of Word in the ROT (running object table). Now, when you close your app, Word is closed too.
Here's another way of accessing Word (this way won't link Word to your process):

Word.Application app =
System.Runtime.InteropServices.Marshal.GetActiveObject("Word.Application") as Word.Application;

This code retrieves an instance of Word from the ROT, but does not "link" it to the running process. When your app is closed, Word
is not.
If "app" = null then run the following line, and then run the above line once more (again testing for null!):

System.Diagnostics.Process.Start("Word");

GL

 

[gizmo]

Thanks Dave...

I am familiar with the Word Object Library from VB6 days and wanted to
avoid it for a number of reasons....

1. The application we are developing will launch the windows default
application depending on the extension of file being opened, e.g. txt
files will launch notepad. In the case of .doc files it will open
Word, however we want this as flexible as possible so there may be a
situation where .doc files launch something other than Word.
2. Possible version conflicts, between version of word installed on
client machine and version of Microsoft Word Object Library that the
application has a dependency on.

It may be the case that we need to cater specifically for Word (and
Excel) due to the way it manages multiple documents within the one
process; this being the case the Word object library may be the way to
go, so I have managed to take your suggestion and build a prototype
and will bring it to the table as a squareish peg for the round hole.

Many thanks for your time and contribution. If you have any further
suggestions they would be much appreciated.

Regards
Gavin

 

[Dave]

It may be the case that we need to cater specifically for Word (and

Excel) due to the way it manages multiple documents within the one
process

Unfortunately, I believe you will have to cater to those apps. If your using the extension mapping, you're program will have to be
aware of MDI apps (as you've mentioned above).

I'm glad I could help.