0

I'm using the following way to get the running instance of MSWord.

MSWord.Window wordWin = null;

uint OBJID_NATIVEOM = 0xFFFFFFF0;
Guid IID_IDispatch = new Guid("{00020400-0000-0000-C000-000000000046}");
Guid iid = IID_IDispatch;

Object accObject = null;

int hr = OleAcc.AccessibleObjectFromWindow(msWordHndl, OBJID_NATIVEOM, ref iid, ref accObject);

wordWin = accObject as MSWord.Window

if(wordWin != null) // <----(1)
{
   // do something.
}

Here msWordHndl is a valid running instance of MS Word handle.

The above code (1) works fine every where except on some of our customers machines.

What are the things that we need to make sure why the msWordHndl is not being recognized as MSWord COM object? i.e. (1) fails always. The same doesnt happen on our machines/environment.

The following have been verified on the customers machine.

  1. Office 2010 plus is installed
  2. Primary Interop Assemblies(PIA) has been installed.
  3. Verified that .NET programmability support is included while installing MS Office.

Update: Running into the same problems as mentioned in Can Microsoft.office.interop.word.dll work without installing office?

But in my case, Office is INSTALLED on the customer computer.

I did verify that the Microsoft.Office.Interop.Word.dll is located in c:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Word\14.0.0...\ One small difference I see is the DLL name is prefixed with "Policy.12.0". To make sure this is causing any issues, I checked in another customer computer where the MSWord access works fine but that computer also has the same prefix to the DLL.

Community
  • 1
  • 1
user1810084
  • 39
  • 7

2 Answers2

1

I just solved my issue. The issue was due to having multiple versions of MS office installation i.e. installing Office 13 and then downgrading to Office 10. That left two keys in the registry.

http://help.turbolaw.com/hc/en-us/articles/200711886-Interop-error-when-creating-documents

This helped in solving the problem i.e. manually deleting the unnecessary keys from the registry.

user1810084
  • 39
  • 7
  • I too got *E_FAIL (Unspecified error)* as Word 2013 and 2016 both were installed, so I uninstalled one and this solved my issue, Also thanks to @Dirk Vollmar – Aniket Bhansali Jul 21 '17 at 14:59
0

The problem here seems to be the handle that you are passing to AccessibleObjectFromWindow. You need to pass a handle to the actual "accessible object" which is the child window of the main Word window of class "_WwG".

You will find sample code how to do that here:

How to access Microsoft Word existing instance using late binding

If the above sample does not work for you, it helps checking the return value of AccessibleObjectFromWindow.

Community
  • 1
  • 1
Dirk Vollmar
  • 172,527
  • 53
  • 255
  • 316
  • Hi, Thanks for the quick reply. We are indeed passing the handle of the child window. This works fine in our env but not on customers so wondering if there is anything wrong with the Office installation or registry keys on the customers machines. Thanks! – user1810084 Nov 25 '15 at 15:18
  • What does `AccessibleObjectFromWindow` return in case your code fails? And is the _WwG handle still valid at the moment your call `AccessibleObjectFromWindow` ? – Dirk Vollmar Nov 25 '15 at 15:24
  • The return value is zero and the Handle is still valid. I did verify again to make sure. I'm running to the same problem as mentioned in http://stackoverflow.com/questions/19576080/can-microsoft-office-interop-word-dll-work-without-installing-office except that msoffice was INSTALLED on production computuer – user1810084 Nov 25 '15 at 17:50
  • May be customer "installation policies" making Microsoft.Office.Interop.Word.dll to be not accessible some how? Just a thought. If that is indeed the case, is there a way to confirm that and point to the customer? That would also unblock the customer. – user1810084 Nov 25 '15 at 18:01
  • Thanks @Dirk Vollmar for trying to help. I solved the problem and posted as answer. – user1810084 Nov 25 '15 at 20:36