I have been trying to create a macro that will automatically run when I open a new word document that will verify that tracked changes are turned off. For some reason, whenever I run a macro that opens a new word document that is a .dotm file that contains a form, it turns on tracked changes and I have not told it to do so.
I have tried various different ways of fixing this issue.
Before I close the User form that has been opened when I opened the new file, I add this line
ActiveDocument.TrackRevisions = False
I also tried with an if statement
if(ActiveDocument.TrackRevisions) then
ActiveDocument.TrackRevisions = False
end if
I also tried doing it so that it was not even involved in the user form at all but the document itself by inserting it in the "ThisDocument" section under the "Microsoft Word Objects" File. Here is what is located there.
Private Sub Document_New()
UserFormInfo.Show
'ActiveDocument.Bookmarks("cursor").Select
ActiveDocument.TrackRevisions = False
ActiveDocument.Save
End Sub
I expect to have this turn off tracked changes, however, this does not occur. Any help is appreciated.
What ended up working for me is I had to remake my template. I had to export my user form so that it was fully removed from all my word files and then remake the template, after that, I had no problem with tracked changes turning on when I ran my macro to open this template. I believe it was a setting I must have had turned on when I had made my template.
Related
Using Word 2013.
I found this previous question that is similar, but there was no accepted answer, and I'm not trying to build an add-in, so I hope I don't need something complex.
I have AutoNew and AutoOpen macros in my Normal.dotm. They are working great except that neither one of them fires when I open Word from the taskbar or other icon. In that situation, Word opens with the blank "Document1," but without the initialization I want.
Suppose my macros display a message with the document's name when a document opens or is created. I know this is silly, but it seems like a workable example.
If I open a document by clicking on it in File Explorer or by using File | Open or File | New, then the appropriate macro will fire and the message will pop up.
But if I just open Word from scratch, then no macro fires, and there is no message displaying "Document1."
I tried AutoExec to cover this situation, but when AutoExec fires, there is no active window and no document loaded yet.
Ideas?
The example cited in the question not "workable" because it makes no sense to want to show the name of an automatically generated document.
In any case, only AutoExec will fire when the Word application is started - this is by design. AutoNew does not fire when Word creates a new, default document when the application starts. (You'll also notice if you immediately open another document, without doing anything to the default document, that document is closed automatically. In a manner of speaking, this default document doesn't exist until the user takes action on it.)
What can work is to explicitly create a new document during AutoExec. This will have the effect of generating a document in place of the default document. The document will have the same name as that default document. The only different would be that this document will not close automatically when another document is opened.
When the document is created then AutoNew (and Document_New) will be triggered.
Sub AutoExec()
Documents.Add
End Sub
In Word 2016 64bits AutoOpen is triggered before AutoExec.
So if you Open a file, when AutoExec runs you can open a new file only if there is no file already opened.
As a result when you open a file you don't have another blank document opened as well.
In Word 2010 and 2013 AutoExec is triggered before AutoOpen.
So the solution cannot be applied.
But you can ask Word to close the blank file in the AutoOpen macro.
Have you tried just adding code for the Document_New() and Document_Open() events in your Normal.dot file? I just tried it with mine and however I opened the test document I got the Document_Open() to fire. The Document_New() worked as well.
Screen shot of my setup for testing. The relevant msgbox includes the name of the document.
In our office we are currently using templates containing macro's. We are about to upgrade to Office 2016, but unfortunately the macro's don't work completely as they used to.
The current implentation is that a template is opened from a custom dialogue, and that a Document_New() is called in the template. This does not seem to work anymore: the Document_New() is only called when a template is opened from the file explorer, not when it's opened by a Documents.Add() in another macro.
Alternatively, I found a lot of solutions where Documents.Add is called, and then other functions are being invoked on that new document. For example
Set doc = Documents.Add(Template:=strSkeuze, NewTemplate:=True)
Call MsgBox(doc.Name)
In Word 2016 this doesn't seem to work. The MsgBox isn't invoked and when I step through the code in debugging mode, the code stops executing after the Documents.Add().
However I cannot find anywhere that this is a known change and I am looking for a workaround to still execute code, either from the template like with the Document_New() or from the parent Macro that opens the document.
Could someone tell me whether this is still possible and how to solve this?
You ought to be able to detect the added document using the Application's Document_New event, either that it fires (presuming that you have been using the Document's Document_New event) or by generating the event artificially by counting open documents on the first action taken after the document is added.
There are several instances of this problem, but this one is predominant. This is in relation to updates (our most notable problem child being KB2726958). We have a Leave Spreadsheet that looks like this:
Leave Spreadsheet example
By pressing the grey Leave button, you end up here:
Leave Word doc
All the programming for these is written in VBA (i've never worked with VBA before, I can understand it to a degree).
Now, the issue is that using the ActiveX button in the 'Leave Spreadsheet example' causes the 2 buttons 'Send by Email' and 'Save' to switch functions; Send by email attempts to save and save opens up Outlook and creates the email message.
Both functions have completely retained functionality, just on the wrong buttons.
The thing I find weird is that a hyperlink to the very same file works; the buttons aren't switched and have full functionality. The only hint that I have towards resolution is that when using a hyperlink, it's directly opening the file. When using the ActiveX button, it seems to be creating a new file based off the file it's linking to. For example, the hyperlink directly opens C:\Report.dotm but the ActiveX button opens Document1.doc with a template based on Report.dotm.
I'm considering that maybe the activeX button is opening up Word with an incorrect extension? But i'm not sure how to figure this out (code below shows that the linked file on the activeX control is a .dotm).
What further throws a spanner into the mix is that it only affects some computers... Considering on-site we all use the same type of PC with the same image... :(
My question is, does anyone know why they may be swapping? They're located on the same network drive albeit different directories. They require the same permissions to access. The code for the buttons is as follows:
Excel Button:
Private Sub CommandButton1_Click()
' This button links the excel spreadsheet to the word doc
Dim wrdApp As Object
Dim wrdDoc As Object
Dim i As Integer
Set wrdApp = CreateObject("Word.Application")
wrdApp.Visible = True
Set wrdDoc = wrdApp.Documents.Add("\\networkdrive\directories\Request for Leave.dotm")
End Sub
Word buttons 1 and 2:
Private Sub cmdSend_Click()
' This is the code for the button 'Send by Email'
MsgBox "Send the following email to your Team Leader/Line Manager", vbInformation
SendDocumentAsAttachment "", "IPL Request for Leave"
End Sub
Private Sub cmdSave_Click()
' This is the code for 'Save'
modSend.SaveLeaveForm
End Sub
Please Note: The comments above are not in the code in VBA, i've written them in myself in this question to provide clarity.
Troubleshooting that i've done:
Removing all .exd files
Running the MS Hotfix (removes all .exd files in a GUI)
The next step would be to try running all 6 patches related to fixing ActiveX controls with the particular patches we've done to see if that fixes the problem. The reason I haven't done this yet is because of ITIL (Change management) although I may try testing this later today.
What is the outcome i'm after?
Ideally, I want to understand what is causing these buttons to, from what it looks like, swap their functions. I have different scenarios of button swaps, some of which are remedied by removing the .exd files, and some that aren't.
By understanding what is happening, I hope that I can apply the knowledge to the other scenarios (same problem, different coding).
Then, I'll be able to document my findings so that when we perform the next round of patching that is known to break ActiveX controls, my organization will know how to deal with it.
So the patch mentioned below has fixed this issue. There's still some other issues that I need to test this patch against, but I definitely should have started there. Lesson learnt.
From my work email:
I’ve just tried using the patch related to the ActiveX controls breaking, KB2920754. I’ve used it on two PC’s here in the training room; both had different issues:
- The first one had buttons that had switched around (save attempted to email, email attempted to save)
- The second one couldn’t use the buttons at all.
This patch cured both w/o requiring a restart or logging out and back in. I didn’t remove any .exd files, either.
It does state, however:
“Important For this fix to be fully effective, you also have to apply the other patches for Office 2013 that are listed in the "Resolution" section of the following Microsoft Knowledge Base article”
There are 6 in total.
Patches:
1. KB2920754 – (the one I’ve used successfully)
2. KB2956145
3. KB2956163
4. KB2965206
5. KB2956176
6. KB2956155
I have multiple files with the same VBA code in them, which will most likely have to be changed over time. I don't want to go one by one and c/p the code, so one obvious idea that came to mind is to have one centralized document with the code (template?) that all files refer to.
I found a few topics here at stackoverflow, but none of them work for me or are inconclusive:
Run external vba-code in MS Word
Centralized VBA code (one file) for multiple workbooks
Calling an External VBA from VBScript
Any ideas?
Yes, your idea of centralizing the code in a template and attaching that template to the various Word docs will work. These pics are using Word 2007 but I think it's pretty similar for newer versions. First create a new document and put the code in a Module (named "CommonFunctions" in the picture):
Save the doc as a macro-enabled template:
Now make a new document, save it as a *.docm (necessary for it to run code because a *.docx is macro-free), and attach the document template as shown below. (An alternative is to put the *.dotm file in the startup directory C:\Users\<username>\AppData\Roaming\Microsoft\Word\STARTUP, which loads it automatically.) If you don't put it in the Startup, you'll see the name but it won't be loaded (ie, checked), but you can load it in code, as I'll show.
Make a user form in this document:
Put this code for the button's click event:
If AddIns("c:\_b\MasterDocWithFunctions.dotm").Installed = False Then
AddIns("c:\_b\MasterDocWithFunctions.dotm").Installed = True
End If
Application.Run "CommonFunctions.Test1"
Application.Run "CommonFunctions.Test2"
Notice how the code can load the AddIn for you, because it won't be automatically loaded unless you put it in the Startup directory. This pic shows how the AddIn is referenced but not loaded. You need the checkbox to be able to call code in it. If you don't load it using code and don't put it in the Startup, then the user will have to manually put a checkmark everytime the document opens.
Now the form should work when you click the button. Notice how it can call both public and private functions. The Private keyword definitely shields one module from another, but it seems like modules that are called from an AddIn are considered to be part of the same module, not sure why? Also if you don't put Public or Private at all then VBA considers it Public, I'm pretty sure.
I have a macro that creates a new document based on a template stored on a network share. This macro is stored in each user's Word\STARTUP folder as the file "macros.dotm" and is executed by a button added to a toolbar.
The template file gets locked as soon as the macro code is executed and stays locked so long as the derivative document is still open by another user.
It has no impact on their ability to open new documents based on the macro, but if I want to edit the template, I have to ask them to close Word (and hope nobody else goes into it).
Macro code:
Documents.Add Template:="F:\templates\letterhead.dotm", NewTemplate:=False, DocumentType:=0`
One way around this is detaching the document from the template after it is generated:
Dim doc As Document
Set doc = Documents.Add(Template:="F:\templates\letterhead.dotm", NewTemplate:=False, DocumentType:=0)
Set doc.AttachedTemplate = Nothing
Alternatively, change the filesystem permissions on the template so only you have write access.
The issue is that the template is on a network drive - this is a pretty common issue. One way to get around it is to have your calling template copy over that template locally first and then create a new doc based off of that (and then delete the template when done).