Trusting Documents

[ASkolnick]

How do you make a specific document a Trusted Document?

I am not looking to make a location Trusted, since I don't want every document in the location I am forced to go to be trusted.

Any help is greatly appreciated.

[Paul_Hossler]

Word2010, Vista

When you open a document with active content, you get the message bar (something like "Macros, Enable, etc.)

BEFORE you enable, click on [File].

[Info] is pre-selected, and the [Enable Content] is displayed

Click the little triangle, and then [Enable All Content]

The online Word help under 'Trusted Documents' has a good write up

Paul

[ASkolnick]

I actually did that to make it a trusted document, but it still seemed to break the certificate once the reference was added even though both the template (.dot) and the document (.doc) were both signed.

[Frosty]

If you change the programmatic references of a project, any existing digital certificates are invalidated. If this did not happen, then trust certificates would be meaningless. Everyone's computer is fine *before* a virus changes it... ;)

[ASkolnick]

That is sort of the direction where I think the problem is so now I have to figure out how to save without the added reference.

But I don't particular agree that this should be the behavior if the
a) Attached Template is certified and
b) The Document is also certified.

[Frosty]

They are certified... but once you make a change, then it is no longer certified. There is no way to validate whether the change is malicious or intentional. Certificates are designed to make unchanging things trusted. When you upgrade an application, it requires new trust certificates. That's the way it has to work. Computers don't intrinsically know which changes are malicious or not.

Based on this and the other thread, I think you may be trying to do something that is simply not the way to do it, and so you are trying to solve a problem you shouldn't need to solve.

There are, of course, other ways of "trusting" things which don't require a security certificate, but without knowing the big picture of your design, it is tough to give you specific advice.

[ASkolnick]

OK. Did some more experimenting. Any ideas would help.

Object: Minimal code in each individual form and attach to a code set (Will talk about issues with each attachedtemplate versus Global Add-Ins)

Global Add-Ins: Global Add-Ins are problematic because the code set holds global variables for Toolbars. We can have two documents open at the same time with two different toolbars. Their settings are based on a style sheet. So, this way did not work.

AttachedTemplates: The attachedtemplate worked since if a 2nd word document was created, a 2nd attachedtemplate was used. This worked perfectly fine for multipledocuments and everything saved. However, it saves a reference to the attached template therefore breaking the digital signature.

If we try to off-load some of the code such as the save and save after the AttachTemplate becomes detached, as soon as the attachtemplate detaches, the code stops running even though the code is running from the main document not the attached template.

Yes, one option that we have is to make the location trusted and not worry about the certificates, but we are not sure that would be opening a different loop hole.

[Frosty]

I think the easiest way to do this would be to simply make the location trusted. If it is a custom location (i.e., you're not trusting something that a malicious virus could find the location of by looking through the registry, or a "built-in" or default location like Microsoft Office\Office14\Startup), then you're unlikely to open up an area that any virus could decide to deploy from.

But the description of your desired end-result (a dynamic user interface based on the active document, and a way of managing those dynamic user interfaces), is not something particularly strange... although the mechanics of this differ greatly from Word 2003 (and previous) vs. Word 2007/2010... because the toolbars/commandbars User Interface vs. the Ribbon User Interface have their own issues which need to be addressed.

Based on your comment about toolbars, it sounds like you are working in 2003, but trusted locations is only something which exists in Word 2007/2010.

Which system are you actually using, and what user interface components are you trying to have be dynamic? I'm unclear what you mean by "a style sheet" as that is typically something which is part of web-design.

Without re-engineering everything you have, a couple of additional brainstorms:
1. Try Application.Run or Application.OnTime to call an external macro in a global addin which handles removing the attached template and performs saves, leaving most of your code dealing with the UI in the attached template.

2. Utilize a global addin to open any attached template in a hidden manner during AutoExec (i.e., when Word Starts) and which closes them at AutoExit (look up "auto macros" in help), so that even when the template is removed from the attached template of a document, the template isn't actually unloaded -- of course, this makes those attached templates pseudo-global addins.

But there is no way to have code in an attached template continue processing when, as you say, you remove the attached template and that template is closed. It is akin to putting an "End" in your code.

I still suspect there is a better way to architect your entire package (saying that the reason Global Addins are problematic is because the code set holds global variables for toolbars, just means to me that you haven't worked out or understand a scope issue with your code well enough).

What do you mean you might have two documents open at the same time with two different toolbars? You can still only have a single Active Document at a time. Even if the documents are side-by-side... the Active Document is the one that any visible UI is handling.

If you need to reconfigure UI elements when you switch/activate to a new document, then you should look at Word events, specifically the Document_Change event.

But your issue doesn't sound like a limitation of the global addin concept, but rather something to do with scope of variables. Public variables are dangerous to use if you don't really understand scope.

Again, sorry to be unspecific in terms of new ideas to try... but it seems like you're trying to address two immutable issues (trust certificates on constantly changing documents/templates and code continuing to run when the project containing the code has been closed) because there is something architecturally unsound about your entire code process.

[Frosty]

Additional note... in the past I have handled dynamic UI elements in one of two ways:
1. Have all possible UI elements contained in a Global Addin. Utilize the document_change event to test what "type" of document is active, and then display the appropriate UI elements to that active document.

2. Put custom UI elements in to appropriate templates, but those UI elements simply called "stubby" routines which were redirected (in some fashion) to code which existed in a global addin.

In almost all cases, it was easier to manage and deploy code from a central location, regardless of where my UI elements are stored. However, it is not inappropriate to utilize a 3rd way:

3. Custom UI in an appropriate template, and all code dealing with documents of that "type" contained in that same template.

However, if you are utilizing the .AttachedTemplate property of a document as a back-door way of switching access to a different code project for a document, I think you are going to continue to run into problems, as this was not the design intent behind the .AttachedTemplate property. The design intent was to have a "Letter.doc" document attached to a "Letter.dot" -- and have all "Letter" appropriate code contained in the "Letter.dot" so that any documents based on that template had access to the "Letter" code.

In short, it wasn't something which was supposed to be switched around all the time. And Microsoft has things hard-coded to actually look for an attached template of the same name in a couple of different places, if it doesn't find it in the original location. For example...

1. Letter.doc attached to "F:\companytemplates\Letter.dot"
2. user opens up Letter.doc, but doesn't have an F:\ drive.
3. Microsoft will automatically look for something called "Letter.dot" in a number of the paths indicated in File Locations area (generally looking into the UserTemplates and WorkgroupTemplates paths, although there are a couple other places it will look too).

In short-- Microsoft is doing work to try and "fix" a "missing" attached template. If you're always swapping this around, you're kind of swimming against the current.

[Frosty]

If you don't want to post code... can you at least describe the exact process and what code does what (and from where) during the following steps:
1. Starting up Word
2. Creating a new document ("NewDoc") based on TemplateA
3. Whatever you do with "NewDoc" to switch its attachedtemplate to TemplateB
4. What happens when you Save "NewDoc."
5. What happens when you close "NewDoc."
6. What happens when you re-open "NewDoc"

I'm having a hard time even visualizing specifically what you're trying to do, and where it's failing (apart from the obvious-- TemplateA instruction to change .AttachedTemplate property to TemplateB ceases running any further code in TemplateA in certain cases).