When I create a new document based on a template (*.dot), I need to know on which template is the document based on.
Is there a way to find out with VBA which template was used for creating this new document? I need the complete path to the template.
ActiveDocument.AttachedTemplate.FullName
You may also use a built-in document property to access the template name: ActiveDocument.BuiltInDocumentProperties(wdPropertyTemplate)
I don't remember why theres has been sometimes differences between the two results; you must try it out. please be aware that accessing sometimes the built-in properties sets the document in a dirty state, so that it is useful to save the ActiveDocument.Saved state before and reset it after having accessed the property.
[UPDATE]
I've had again a look into the way you're creating the documents. If it's at your customer with 38.000 templates, I guess your problem are "fake" templates. I've just did a test with Office 2003:
Create a new document "TestTemplate.doc" with same content and save it as doc file. Close it.
Go to Windows Explorer and rename the document to "TestTemplate.dot". This provokes Windows Explorer to treat it as a template, not as a document. The default DDE command for templates is not "OPEN", but "NEW", what you can also see if you do a right-click on the file ("New" is bold, while with documents "Open" is bold).
Double-click the fake template: Word creates a copy of the document, so a new file named "Document2" or whatsoever.
Go to the VBA Editor, and type ?ActiveDocument.AttachedTemplate, and you'll see "Normal" as answer. Type ?activedocument.Type = wdTypeTemplate and you'll see "False" as answer.
Sp I guess the documents "Without template" are only copies of other documents, and not of templates. So you have no way to find the base template.
Related
I'm using Microsoft Word 2016 and looking for a way to run a vba macro that will change the default option to Create bookmarks using: Headings when I save a document as PDF when I click on
File ->
Save As ->
PDF (*.pdf) ->
More options.. ->
Options
Note: The option is only available if you have a table of contents in the document.
The goal is that if a user chooses to save as PDF that option will be already checked.
I'm not asking how to do this manually, like in this question
nor programmaticaly save to PDF using vba like here or here.
Since it's not reachable by VBA at the point of save a file as PDF I do not see it as possible to change that PDF saving option using only VBA.
The only way I see you can reach the behavior you seek is as follow but need some special effort. You need to either create a VTSO addin or be able to have an extra marco file in the Microsoft Word Startup-Path so it will be loaded at Microsoft Word Startup.
Re-implement your own "Save" behavior by overriding the Save functionality (BeforeSave) of Microsoft Word and provide it via your own Save-Button in the Microsoft Word-Menu described here
How do I create a Word VBA personal code library as I have done in Microsoft Excel..? I had this working, but today it broke and I cannot make it work again. I originally did this because my Normal.dot file blew up and I lost all my macros. I found a blog post that described how to do it, but I cannot find my way back there. I've Google this extensively, but not found a solution.
There are some twists & turns here, as described below...
In Microsoft Excel, one can easily create a "code library project". This is simply a standard XLSB file with VBA modules in it, saved in the ..\Excel\STARTUP folder alongside the PERSONAL.XLSB file.
When the VBA editor is open in any other XLSX/B file, the modules in the code library file are always visible. And thre's not a requirement to create a VBA project reference to see them. The library modules can be natively edited as if they were an integral part of any other file, without requiring the library file to be open in another window to do so, as shown in the picture...
However...in Microsoft Word, it seems to work differently, and...strangely. If the same is done: create a DOCM file with custom code modules, and save it in the ..\Word\Startup\ folder, those modules are not visible in the VBA Project Explorer.
Following along the chain of logic from Excel to Word, and do as others have done...save the DOCM as a DOTM instead, and save it in the ..\Templates folder with the Normal.dotm file. Still, it is not visible in Project Explorer.
It's not until Normal.dotm is opened for editing and the library DOTM is added as a VBA Project Reference that it finally appears in the Project Explorer, but only while Normal is open. Plus...it opens the code library file for editing in another window..! If Normal is saved with that reference, and a new document is created from it, the library code cannot be edited and displays the error "project is unviewable"...
It's not until the library DOTM file is opened for editing in a second window that it's code becomes editable, and it does so in all Word VBA windows on all documents at the same time.
There is one glimmer of hope: if I create a new blank DOC from the library DOTM instead of Normal.DOTM, it works..! Any document created from the library retains a link to the code modules there, including any new or edited ones, and they can be edited natively right there in the Project Explorer. And this includes the code modules in Normal.DOTM too.
It seems the "editability" is one way: documents created from any other template can see & edit both their own code and those in Normal.DOTM, but not the other way around: documents created from Normal.DOTM can only see their own code.
How can this connection be made two-way for all documents, regardless of what template they were created from..??
I've been trying to wrap my head around the possibility it may be a security/malware issue, but I can't come up with one. If macros are already enabled in the Trust settings, malware is already 99% on the way to controlling a machine anyways. The only step left is enabling VBIDE.
A very similar question on Microsoft Answers:
Is there a startup or template file in Words that allows one to store "personal macros", i.e. macros that one wants to have always available while editing documents (I am seeking the equivalent to the PERSONAL.XLSB file in Excel, where I can store macros that then are available in all sheets that I open).
And the solution given:
Word uses the default template Normal.dotm for this purpose. Macros stored in Normal.dotm will be available in all documents. Apart from that, Normal.dotm also serves as the default document template, and it also stores the user's formatted AutoCorrect entries.
Just like Personal.xlsb, Normal.dotm doesn't exist in a clean new installation, but it will be created when needed.
The location for Normal.dotm is
C:\Users\<username>\AppData\Roaming\Microsoft\Templates
AppData is a hidden folder, so you must display hidden files and folders in order to see it in Windows Explorer.
Similar questions (also on answers.microsoft.com) have been offered same type of solution.
Macros that should be globally available can be stored in Normal.dotm or in a template located in the Startup folder for Word. See also:
And:
In Word, personal settings (those that aren't stored in the Registry) are stored in the Normal template, Normal.dotm. When you change and save settings or create macros, they are automatically saved in Normal.dotm unless you choose to save them in another template. Normal.dotm is automatically loaded when you start Word, and new Blank Documents are based on Normal.dotm.
I keep the template for the files I am working with in a dropbox and when I change to a computer with a different dropbox path, the template needs to be re-attached to the document. I would like to do this with a macro.
I can still see the name of the originally attached template in the "Templates and Add-Ins" Window, so the information must be somewhere stored within the document.
If however I try to retrieve the Name of the previously attached template via VBA by writing
strTemplate = ActiveDocument.AttachedTemplate
the result will be "Normal.dotm" and not "MyTemplate.dotm", which actually makes a lot of sense, but isn't what I am looking for.
Is there any way to retrieve the name and path of the previously attached template?
I think you can get the ful name (path+name) from
Application.Dialogs(wdDialogToolsTemplates).Template
and the name alone from
ActiveDocument.BuiltinProperties(wdPropertyTemplate)
The first time I tried the first of those, it didn't seem to work, but I could have been checking the wrong document. You won't find the Template property documented under the Dialog object - it's documented here
If those do not work, the only other ways I can see to do it would be
a. to look inside the .docx while it is closed (for a .docx), or maybe (I haven't checked) use dsofile.dll for a .doc, or
b. insert the field { template \p }, execute it and retrieve its result text
I found the answer here on stack overflow (unfortunately only after posting my question) as an answer to "How to open a word document without resolving the attached template?":
strOldTemplate = Dialogs(wdDialogDocumentStatistics).Template
In an ordinary document list in SharePoint 2010 there are two buttons for adding documents: “New document” and “Transfer documents”. New document usually opens a blank word document, and Transfer documents usually gives the possibility to choose a document to add to the list.
In a document library in our environment, the New document button opens the form to upload an existing file rather then open an empty word document.
Why does this happen? Is there a setting that specifies this behavior?
It happens when there are no default templates, possible due to custom content types with no set default document template (word, excel, etc) pherhaps due to upgrade from SP 2007 to 2010?
Quick fix: Add document template to the custom content type and add document should reappear.
In sharepoint 2007 document library, when documents are uploaded, across each documents there is an option that allows us to 'Edit properties' for that document. How do we disable this option. We wish to disable this option so that our users do not mess up the properties fields in there.
Thank you,
Mahesh
As noted on SharePoint.stackexchange.com: In SharePoint 2007 you'd have to modify core.js. (Or copy core.js, modify the copy and create a custom masterpage that includes the copied core.js instead of the original - since modifications on core.js are not supported.)