Remote control of Word no longer working

[Rüdiger Paschotta 2]

In Delphi XE3, I have been using remote control of Microsoft Word via TWordApplication, e.g. for assembling quotations from multiple documents; it mostly worked fine, even though it sometimes hanged and needed a restart of my program. Now it suddenly stopped working: when I call WordApplication.Connect (the first step), in unit WordXP, line 30576 (procedure TWordApplication.Connect) it always raises an exception "Interface not supported" in the line containing: Fintf:= punk as _Application;

It seems it can no longer establish the interface with Word.

 

In Delphi, Components | Install packages, I find that (as usual) "Microsoft Office XP Samples Automation Server Wrapper Components" are enabled, but not the similar stuff for Office 2000. It had always worked like that.

 

I migrated from Office 2013 to Office 365 a couple of weeks ago. Remote control of Word continued working, only now it stopped. I wonder whether an update of " Microsoft Office Click to Run" might have broken it.

 

I tried several things without success: starting the Office 365 installer again, and Start menu | Apps and Features, searching for Office, making a " quick repair" for various items.

 

It seems that Office is broken, not my program - right? Any ideas how to fix it?

Edited May 19, 2020 by Rüdiger Paschotta
added tags

[Guest]

This may come across as a non-answer. I would strongly recommend not to use OLE. Rather checkout all the non-GUI solutions to massage docx-files. It is possible with most formats. I have written my own parser, but i seem to remember there are solutions out there. HTH.

[Rüdiger Paschotta 2]

Well, Delphi comes with TWordApplication - it seems natural to use that instead of trying with third-party stuff. Anyway, I would consider it if someone can suggest a good third-party solution.

 

I am actually not sure what you mean with "non-GUI": not even remote controlling word, but making Word files directly?

[igors 0]

Perhaps it's related to Office, I also have 365 and OLE interface works.

Before OLE was only supported in Professional Office versions, I don't know if there are multiple versions for 365.

[David Heffernan 2353]

Automating Word for document preparation is known to be somewhat brittle. More robust is to generate Word documents directly without invoking Word at all. There are good libraries for doing that. That's the point.

 

If you are going to rely on Word for this then it pays to be very careful about the version that you use. Switching to Office 365 is simply asking for trouble. 

[miab 25]

@Rudiger,

For this I remember, the Microsoft Office Click-to-Run version is "OLE free".
Try to uninstall it (everything related to MSOffice) and install only the full version.

---------------

Maybe it will help:

https://answers.microsoft.com/en-us/office/forum/office_2016-office_install/office-click-ro-run-and-ole-automation/abc2fe0d-58e4-42eb-84ef-a6e7c1c7b3f4

Edited May 20, 2020 by miab

[Guest]

Yes, as @David Heffernan says. You parse the files using your own code or a 3rd party library.

 

There are expensive .NET solutions out there for a lot of functionality. Me, i prefer native-delphi code, especially server-side, so i use some 3rd party solution for reading doc and pdf and my own parser/patcher for docx/xlsx files.

 

Check out https://docs.microsoft.com/en-us/office/open-xml/open-xml-sdk for inspiration. Somewhere there is a tool to inspect the underlying xml protocols of a doxc file. Very useful even if you are not using microsofts tools.

 

Also scalabium, http://www.scalabium.com/.

 

IMHO (humbly) the application <=> Word automation stuff can break for a host of reasons, so for anything other than hobby projects i choose another solution.

 

HTH

[miab 25]

But only OLE will ensure 100% compatibility MSOffice format.

[Rüdiger Paschotta 2]

Many thanks to everybody for contributing your thoughts!

 

It is an interesting suggestion to produce Word documents without OLE. Indeed, the automation is somewhat unstable and slow, and I don't nearly need that for my purposes. On the other hand, I'm afraid it could be very time-consuming to (a) identify a suitable library and (b) to get it working with that. What I need is basically to combine a couple of smaller Word documents to a single one and also to do certain replacements in the text. If anyone can suggest a suitable library, that could be very helpful.

 

I do not understand this Office Click-to-Run stuff. Under "Apps and features" I actually cannot find it, so I suspect that my Office installation is not based on that. it is just that Avira Software Updater  has recently reported to have updated " Microsoft Office Click to Run".

 

I do not believe that the move to Office 365 has caused the problem, since the current problem started only several weeks after that.

[David Heffernan 2353]

47 minutes ago, miab said:

But only OLE will ensure 100% compatibility MSOffice format.

Nah, that's not true.

[Rüdiger Paschotta 2]

I finally found the solution for the problem with "interface not supported" when trying to remote-control Word: I had compiled my program for the 32-bit Windows platform, while Office 365 is a 64-bit version. Going back to a 64-bit version, everything worked again! When previously changing the platform, I could not anticipate that side effect. That nasty problem has taken hours to be resolved.

 

I first tried to find some library for directly manipulating Word files, but could not find anything which looked reasonable. It would not only have to work theoretically, but be documented such that one can use it without wasting a lot of time. Here, many packages fail.

 

I also previously tried a "repair" of my Office installation, which did not solve the problem but apparently uninstalled Microsoft Teams.