Use a built interface for Office

[feerrenrut]

Longer term it may be beneficial to use a built interface for office rather than the current IDispatch method.

Currently using IDispatch, calling a non existent method is safe, it does not result in a crash. However using the built interface this would cause a crash. We have at least one method that was added in office 2010, however we need to support back to 2003. We don't know how many methods are not in office 2003.

Some questions are:

• Do methods use the same GUIDs between versions of the generated interface eg (2003 vs 2007)?
• How many methods do we use that are new to the 2007 interface?
• How should we call methods that are added to new versions of the interface?

[feerrenrut]

The work previously done on this topic:

See branch: experiment_useCompiledMSWordInterface see diff

Building office headers using visual studio 2015

• Create a new C++ console application, no precompiled headers
• add the following to the top of the file:

 #import "C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE15\MSO.DLL"
 #import "C:\Program Files (x86)\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB"
 #import "C:\Program Files (x86)\Microsoft Office\Office15\MSWORD.OLB"  \
   auto_rename, \
   raw_native_types, \
   rename("ExitWindows","MsoExitWindows"), \
   rename("FindText","MsoFindText"), \
   named_guids

See https://msdn.microsoft.com/en-us/library/298h7faa.aspx for these attributes. Or search for "MSVC #import Attributes"

The attributes we use:

• auto_rename - Renames C++ reserved words by appending two underscores
  (__) to the variable name to resolve potential name conflicts.
• raw_native_types - Disables the use of COM support classes in the
  high-level wrapper functions and forces the use of low-level data
  types instead. To be compatible with existing code we want to use
  BSTR rather than _bstr_t
• named_guids - Tells the compiler to define and initialize GUID
  variables in old style, of the form LIBID_MyLib, CLSID_MyCoClass,
  IID_MyInterface, and DIID_MyDispInterface.

The files created:

• have wrapped functions that emit C++ exceptions in the style:
  • long MoveEnd ( VARIANT * Unit = &vtMissing, VARIANT * Count = &vtMissing );
• and have unwrapped functions (no impl) that do not emit exceptions in the style:
  • virtual HRESULT __stdcall raw_MoveEnd ( /*[in]*/ VARIANT * Unit, /*[in]*/ VARIANT * Count, /*[out,retval]*/ long * prop ) = 0;

Note use _variant_t instead of VARIANT.

[LeonarddeR]

@feerrenrut: Couldn't we just build the interface for Office 2010 and fall back on IDispatch for older versions?

[feerrenrut]

Possibly, there is a question around whether this work is warranted if we are moving to UIA. However I do believe this would significantly clean up the code base for supporting older versions of word. I don't think there are any blocking issues here, but it's not a priority for us at the moment.

[Adriani90]

cc: @michaelDCurran

[feerrenrut]

Converting excel code base (because it is smaller than the MS Word code) was investigated in PR #9257 see #9257 (comment)

In the generated excel interface, many methods take VARIANT params. The construction and retrieval of values from VARIANT params bloats the code. This doesn't seem to be the case for the word interface, which should still be investigated when an opportunity arises.

[LeonarddeR]

@feerrenrut Is this still in scope somehow? Note that Word performance is still not ideal when using the object model.

[feerrenrut]

I don't think this would have any impact on performance. The main goal was to improve code readability, and thus reduce errors, and speed up development.

As an example of this see: the diff of winword.cpp line 1056

[Adriani90]

Now the performance is also quite good with the last NVDA Alpha, even without UIA enabled. However, since the support for Office 2007 will completely end in 2023, I wonder if this still needs to be implemented at all to maintain backwards compatibility with Office versions before 2010?

I think this decision is better taken by nV Access.

[Adriani90]

Support for Office 2010 and 2013 ended in 2020 and 2023 respectively, so I guess this doesn't need implemented anymore, especially given that UIA is used as an alternative which needs to be continuously improved.
cc: @seanbudd, @SaschaCowley what is the official position of NV Access on this one?

[seanbudd]

Yes, I think it makes sense to close this. I don't think this is worth the engineering effort given this is legacy code to eventually be shifted to UIA