none
How to cast Template object to a Document RRS feed

  • Question

  • I need to gain access to the Variables stored in a document Template attached to my Document object, and was hoping i could simply cast the attached template object to a document object.

    Is it possible to explicitly cast the Template as a Document?

    If not, can i use Template.OpenAsDocument invisibly, so that the template does not actually open in the Application Window?

    Or do i need to get dirty with the OpenXML and gain access to the Template's Variables that way.  If so, any pointers in doing this?

    I've had success using the following:

    msoWord.Template template = (msoWord.Template)myDoc.get_AttachedTemplate();
    msoWord.Document tempDoc = template.OpenAsDocument();
    msoWord.Variables dvs = ((msoWord.Document)tempDoc).Variables;
    

    where myDoc is a valid Word Document, but this opens the template and i do not want this to happen.

    Tuesday, October 9, 2012 11:35 AM

Answers

  • Hi Matt

    You need to open the template as a file in order to work with its document variables. You can also use the standard Documents.Open command, setting the Visible parameter to False. This won't hide the document entirely - it will be listed under the Windows - but it won't be "in the user's face".


    Cindy Meister, VSTO/Word MVP, my blog

    • Marked as answer by Matt Cope Wednesday, October 10, 2012 1:30 PM
    Tuesday, October 9, 2012 5:42 PM
    Moderator

All replies

  • Hi Matt

    You need to open the template as a file in order to work with its document variables. You can also use the standard Documents.Open command, setting the Visible parameter to False. This won't hide the document entirely - it will be listed under the Windows - but it won't be "in the user's face".


    Cindy Meister, VSTO/Word MVP, my blog

    • Marked as answer by Matt Cope Wednesday, October 10, 2012 1:30 PM
    Tuesday, October 9, 2012 5:42 PM
    Moderator
  • hi cindy
    thanks for your suggestion... that works pretty well.  i'm closing the template straight away so there's no intrusion to the user.  well, so it would appear at the moment.  i'm sure to come up against a possible secuirty issue where i do have the rights to open the template perhaps... but i'll cross that bridge then.

    in the meantime, i've been looking at the OM for the Template interface in more depth, and it has members of CustomDocumentProperties, AutotextEntries, BuildingBlocks etc.  but no Variables collection.  does this mean that i would not need to open the template as a document in order to gain access to these properties of my template instance?  but because Variables is not a member of the Template interface then that is why i need to perform this other task?

    off the top of you head, is either of the following likely to work without opening the template?

    template = (msoWord.Template)m_doc.get_AttachedTemplate();
    msoWord.AutoTextEntries ates = (msoWord.AutoTextEntries)template.BuildingBlockEntries;
    msoWord.BuildingBlockEntries bbes = (msoWord.BuildingBlockEntries)template.BuildingBlockEntries;
    

    (for some reason, despite AutotextEntries being listed as a property here http://msdn.microsoft.com/en-us/library/microsoft.office.interop.word.template_members.aspx, it does not recognise in visual studio)

    Wednesday, October 10, 2012 1:29 PM
  • Hi Matt

    It's a question of how/where things are stored. (Custom)DocumentProperties were designed to be accessed from external sources, Document Variables were not (and are an older technology).

    As I recall, with C# you need something like get_AutoTextEntries. But if you're using a version of Word that also offers BuildingBlocks then you should use those as they're a (eventual) replacement for AutoText. AutoText is still there for reasons of backwards compatibility, but it's older technology.


    Cindy Meister, VSTO/Word MVP, my blog

    Wednesday, October 10, 2012 2:57 PM
    Moderator
  • im (still) using DocumentVariables on the basis that they are hidden from the user and therefore generally cannot be removed or changed unless the user does this by code.  (In my experience, give a user a way to mess around with something and, sure enough, one of them eventually will.  :-)

    so, i should probably use BBs and CDPs in case Microsoft decide to (eventually) dump the ATEs and DVs, yes?

    thanks cindy

    Wednesday, October 10, 2012 3:21 PM
  • Hi Matt

    I would use BuildingBlocks rather than AutoText, unless you have old code that's still running OK with AutoText and are under resource constraints. Then you could put a comment in and leave it for a while, yet. I don't expect AT to "break" any time soon.

    Your consideration about document Variables vs. doc Props is valid and the reason most programmers use doc Vars. You could contemplate moving the data to a CustomXMLPart if you want to be more in line with the current technologies, but that's also not accessible through the Template object.

    Custom XML Parts can be linked to content controls in order to display their values on the document surface (instead of DocVariable field codes). If the content controls are enabled and the user types something, that will automatically synch with the Custom XML Part. Custom XML Parts are designed to be easily accessed in the closed Office Open XML file.


    Cindy Meister, VSTO/Word MVP, my blog

    Wednesday, October 10, 2012 4:36 PM
    Moderator
  • cindy, yet another quality piece of dev info.  thanks.

    whilst spending my time learning the framework and programming with the office interops, i've sadly neglected to investigate some of the new features and practices of the office system.  the main task ahead has been to move all our current tools into dotNET, and i've pretty much been doing that by a simple code transfer process, albeit with plenty of OOP wrapping.   it's now clear to me, after several conversations with you, that  the custom XML parts and the open xml file format  is an area i need to devote some time to and really need to get stuck in!

    now if somebody could increase the number hours in the day.....

    cheers

    m

    Thursday, October 11, 2012 8:58 AM
  • <<it's now clear to me, after several conversations with you, that  the custom XML parts and the open xml file format  is an area i need to devote some time to and really need to get stuck in!

    now if somebody could increase the number hours in the day.....>>

    How well I know the feeling :-)! And for the same reasons.

    What's relevant really depends a lot on what your tools need to do, both in regards to the user as well as the Word documents. Not having any idea about these details, it's very difficult for me to make good suggestions.

    Usually, there's a good business reason for migrating from VBA to .NET. I usually equate this with needing to interact more with a network or something similar. If the job is more document generation than interacting with the user (extending the Word interface to provide tools for having Word do something), then understanding the capabilities of the Open XML file format is very important, otherwise, not so terribly much (yet).


    Cindy Meister, VSTO/Word MVP, my blog

    Thursday, October 11, 2012 1:42 PM
    Moderator