Word Add In

Topics: Developer Forum
Aug 16, 2007 at 9:26 PM
This looks like a really promising project. I am glad I did a google search on this before I set about making my own.

One thing I was considering is integrating this directly into Word. I have been building some InfoPath -> Word report generation mechanisms. They operate by inserting the InfoPath form as a customXML part, with content Controls that are already mapped to the specific InfoPath XML fields. This allows for a lot of flexibility, since the user can always change the report by moving around elements, changing text, etc as a full end user. It works right inside of word.

However, if the InfoPath form changes, or they want to add additional Content Controls, the users are forced to then make a dev request to add the XMLMapping (or use your tool).

Have you thought about exposing this as a word add in and using the ribbon/side panel as another UI to this tool? If not, I'd be happy to lend a hand with it.
Aug 17, 2007 at 4:19 PM
Upon looking over more of your code, since you are using the System.IO.Packaging space, I am not sure that it would be all so easy to edit a document inside word. I think you would have to operate via the OM of the ActiveDocument rather than being able to manipulate the file via disk.

Did you consider going the Add In route, but decided against it for this reason? Are there any specific reasons against it?
Coordinator
Aug 18, 2007 at 5:32 PM
Edited Aug 18, 2007 at 5:35 PM
Hi Kurt

Great questions.

Regarding whether this project can be extended to be used as an add-in; it can be done without much heavy lifting. The reason: the plumbing already exists for specifying different data sources, that is, consider the Open XML package, or the Word object model as a data source). As long as you implement IdbContentWriter and IdbContentLoader interfaces, you can plug in another source of data. Think of it this way, the application itself is just a view and an editor of some data, opening from a particular data source just populates some data structures of custom xml parts and content controls modeled in the data access layer (\src\dal.cs), and saving the data just writes back to that source, using the interfaces to abstract away the details.

From the begining I considered making this an add-in, so I went a bit further then just a flexible architecture, I actually made a stub class for using the Word OM as a data source. See omLoader.cs and omWriter.cs. But those classes are currently not implemented, so that's the starting place. They'll have to be implemented via writing some Word OM code, iterating over the ActiveDocument.ContentControls and ActiveDocument.CustomXMLParts collections. Then one must specify the DataSource.WordOM enumeration as an argument in DbeCore's load method, the rest "in theory" should be taken care of. Disclaimer: I have not tested using the Word OM as a data source so their will probably be some things that need to be changed.

Now why didn't I go the add-in route from the begining?

Main reason: the OpenXML formats just offer so many advantages. By far the best advantage is performance. Rather than slowly interfacing through COM, and calling the OM potentially hundreds of times in a tight loop to populate, I just xpath into a in-memory XML dom (after opening the OpenXML document using the System.IO.Packaging classes). The other main advantage is removing major dependencies, including Word itself. That makes my code more reliable, in that I don't have to write extra code to handle various installation states of Office (what version, inclusion of PIAs, security settings, policies, ect). This makes deployment super easy too -- you just need the .NET framework. If I deploy as an add-in, I'd have to write a massively complex setup, mostly because of the difficulties around deploying VSTO solutions (and you better write it using VSTO, unless you want to write your own add-in shim).

So in short, I used OpenXML because for this particular project, it yeilds faster performance, requires less dependencies, and is significantly easier to deploy, then using an OM / add-in path. That said, OpenXML may not be the right choice of technology for all projects, think of it as just another tool you can use for different scenarios.

The one major downside to using OpenXML though, is that I can't give an in-document experience while using Word itself. Currently now you'll have to open the document in this editor, save, close, then open back in Word. I know that's less than an optimal user experience, so I'd like to in a future release offer an add-in extension. If you want you can go ahead an log a feature request for it (it'll keep me reminded about it and will alert others in the community about it). Note that up until now I have not had any requests besides yours for it, but I'm sure people have thought about it.