none
"Document Assembly" with VSTO 2010 and Word 2010 RRS feed

  • Question

  • With about one week's worth of experience with VS2010, I'm trying to create a VSTO Word Template (at least I think that's the best approach) that will do the following:

    1) Open a multi-page task pane that will collect information about the documents that need to be included in the final output and then collect information about the contents of merge fields in the final assembled document. (I have been able to create a task pane. Maybe this would be better as a pop-up form to fill in.) Years ago, Wordperfect referred to this as a "keyboard merge".

    2) Merge all of the collected information with merge fields in the document. I have tried, in VSTO, to create bookmarks with the same name (failed) and content control areas with the same name (also failed). Word allows multiple identical merge fields within a document ("CustName" repeated many times, for example) so I assume that I'm missing something obvious.

    3) Allow the user to move forward and back through the content collection panes or forms to make changes. Control this via the Ribbon or using controls on the form or task pane?

    4) Ideally, allow the user to open a completed form, make modifications, and repeat the merge to incorporate the new values.

    5) Maintain all of the data within the Word file.

    I have been reading VSTO for Dummies, viewing a Lynda.com program on VS2010, and searching the Web for clues but so far I seem to be asking the wrong questions. I'm hoping that someone can loft a clue (or how-to, sample code, sample files, or link to an explanation) my way.
    Monday, July 4, 2011 4:04 PM

Answers

  • Hi OCG

    1) Ah, WP, how well I remember that (5.1 DOS). Still can't be beaten for "merging"... I'd say a taskpane is a good UI for this, speaking from an end-user POV. If it's a Windows Form you're always running into keeping it on top and the user has to move it around to see what's happening on the document surface... That's just my personal POV :-)

    2) The "politically correct" approach would be to use content controls linked to a Custom XML Part. Your code would write the data to the CXP and from there it would appear in the content controls. This approach would allow you to link as many content controls as you require to the same node in the CXP. Anything the user types into a content control changes what's in the CXP and thus changes the text in all content controls linked to that node.

    Bookmarks: names must be unique. The way to duplicate information is to insert REF fields elsewhere in the document that "reference" the bookmark name, and thus show the content of the bookmark. Drawback: the user can edit only the bookmark instance. (Note: FormFields can work exactly the same way, if you want to apply forms protection)

    Mergefields: I'd stay away from them if you're not linking the document to an outside data source. You can use them, but they won't actually "contain" any data you write to them. And if for some reason they should update what you've written to them will be lost

    Alternatives: Write the data to document VARIABLEs or PROPERTIES (custom document properties) and insert DocVariable or DocProperty fields to display the content. Not so ideal, however, if the user is allowed to edit content on the document surface. (Note: a custom document property supports a very limited number of characters.)

    3) This is a question of the "internal logic" of your project, so it's hard to offer an opinion. My first reaction is that I'd put navigation controls on the same surface where the input controls are. It doesn't seem logical to me to navigate elsewhere (from the Ribbon) unless the pages are very "distinct". Of course, if there's a real logical "break" (say the difference in Word's built-in panes between "styles" and "revisions") then it wouldn't be a problem navigating via the Ribbon.

    4) That will be most difficult if you stick to the merge fields idea; OK with bookmarks; best (from my POV) with content controls or document variables (where the user can't "destroy" the actual data container).

    5) Any of the suggested approaches, above.


    Cindy Meister, VSTO/Word MVP
    • Marked as answer by OrangeCatGuy Tuesday, July 5, 2011 9:38 PM
    Tuesday, July 5, 2011 7:41 AM
    Moderator

All replies

  • Hi OCG

    1) Ah, WP, how well I remember that (5.1 DOS). Still can't be beaten for "merging"... I'd say a taskpane is a good UI for this, speaking from an end-user POV. If it's a Windows Form you're always running into keeping it on top and the user has to move it around to see what's happening on the document surface... That's just my personal POV :-)

    2) The "politically correct" approach would be to use content controls linked to a Custom XML Part. Your code would write the data to the CXP and from there it would appear in the content controls. This approach would allow you to link as many content controls as you require to the same node in the CXP. Anything the user types into a content control changes what's in the CXP and thus changes the text in all content controls linked to that node.

    Bookmarks: names must be unique. The way to duplicate information is to insert REF fields elsewhere in the document that "reference" the bookmark name, and thus show the content of the bookmark. Drawback: the user can edit only the bookmark instance. (Note: FormFields can work exactly the same way, if you want to apply forms protection)

    Mergefields: I'd stay away from them if you're not linking the document to an outside data source. You can use them, but they won't actually "contain" any data you write to them. And if for some reason they should update what you've written to them will be lost

    Alternatives: Write the data to document VARIABLEs or PROPERTIES (custom document properties) and insert DocVariable or DocProperty fields to display the content. Not so ideal, however, if the user is allowed to edit content on the document surface. (Note: a custom document property supports a very limited number of characters.)

    3) This is a question of the "internal logic" of your project, so it's hard to offer an opinion. My first reaction is that I'd put navigation controls on the same surface where the input controls are. It doesn't seem logical to me to navigate elsewhere (from the Ribbon) unless the pages are very "distinct". Of course, if there's a real logical "break" (say the difference in Word's built-in panes between "styles" and "revisions") then it wouldn't be a problem navigating via the Ribbon.

    4) That will be most difficult if you stick to the merge fields idea; OK with bookmarks; best (from my POV) with content controls or document variables (where the user can't "destroy" the actual data container).

    5) Any of the suggested approaches, above.


    Cindy Meister, VSTO/Word MVP
    • Marked as answer by OrangeCatGuy Tuesday, July 5, 2011 9:38 PM
    Tuesday, July 5, 2011 7:41 AM
    Moderator
  • WOW! What an outstanding and detailed reply. I'm going to have to go someplace quiet and think about this but that is exactly the kind of information I was looking for. That doesn't mean I'm out of questions but now I have enough answers to develop a better set of questions.
    Tuesday, July 5, 2011 9:32 PM