Reputation: 1428
If I start an instance of a word application via COM Interop, an instance of Winword.exe is started in the background. If I then subsequently load a Word document from Windows Explorer, it is loaded into the running Winword.exe process that was created via the COM Interop calls.
When my application then closes the COM Interop Application object (because it's done with it), all documents that were loaded into it from Windows Explorer are also shut.
Is there any way to prevent "Native" Microsoft Word from re-using a Winword.exe process that was generated via COM Interop?
Update: Corporate environment so running under another user account isn't feasible.
Update: Word versions range from 2003 on most users machines to 2010 on others.
Update: The workaround described On this KB is only partially adequate as it doesn't work with opening of documents from windows explorer.
Upvotes: 3
Views: 5823
Reputation: 2126
KB188546 provides a workaround for this behavior:
Before you create your Word object, first create a temporary Word object. After you create your object, close the temporary object. This causes Word to act properly when you control it through Automation (that is, if a user interactively starts Word, a new instance of Word is opened for the user). The automation instance remains hidden and separate.
Even though the article later states that this "workaround does not work when a document is launched directly through the Windows Explorer", we couldn't reproduce this. The workaround has worked reliably for us since Word 2016 on Windows 7 (currently using Word 2021 on Windows 10).
The only thing we changed from the original workaround in the KB article is checking if the temporary Word instance has been re-used by an interactive Word session. This might happen when starting Word takes some time (e.g. with slow starting add-ins) and the user starts an interactive session before the temporary Word instance has quit. We determine if the temporary Word instance is used interactively by checking if it is visible (the temporary automation instance is not visible by default).
Code example for C#:
using Microsoft.Office.Interop.Word;
private Application CreateWordApplication()
{
var tempApplication = new Application();
try
{
return new Application();
}
finally
{
if (!tempApplication.Visible)
{
tempApplication.Quit();
}
}
}
Upvotes: 0
Reputation: 19
There are various ways of doing it. One of is before closing the word application through COM Interop. Look into the documents which are open. Close only those documents which has been opened by your application, by keeping records of the documents opened through your application. If the number of documents is zero after closing each of your word documents then close the word application else let it remain open.
I hope the above idea will resolve your problem.If need further help let me know.
Upvotes: 1
Reputation: 4879
Nope, can't stop it. You can "force" word to open a new instance when the icon is double clicked by altering the shortcut and adding a /n or a /w to the command line, but that requires a lot of futzing with the user's desktop and profile.
Better would be for your app to attempt to retrieve the loaded instance, via GETOBJECT, if that fails, start an instance via COM, and when you're ready to unload, simply check for any loaded documents, if there are any that you DIDN'T load, don't unload, and let the user do it.
If there aren't any, then unload word as normal.
Upvotes: 3
Reputation: 3250
There isn't a simple/elegant way to do this. (Atleast not one that I have found in the last few years of looking). But depending on your scenario there might be specific workarounds that fit the bill.
I've resorted to invoking COM Interop for word from an account that is different from the one that real users would login with. That has worked reliably so far.
Would that do the trick for your scenario? If not do share your scenario. Also, what version of Word are you programming against?
Upvotes: 3