AutoExec (Word 2003)

Topic

New Reply

I have a .dot file stored in Word’s startup directory which contains a module with a sub called AutoExec which will not run automatically. Has there been a change in Word so that .dot files in the startup directory are not loaded when Word starts?

Reply | Quote

Replies

If AutoExec were not longer executed, it would break so many applications it wouldn’t be funny. On the other hand, the move toward having to “sign” projects could be affecting global add-ins. Couple things to check:

1. When you start up Word, are there any command line switches (such as /a or /m) that could be interfering with its normal behavior?
2. Are you trusting all installed add-ins and template? In Word 2002, this setting is under Tools>Macro>Security>Trusted Sources (tab). Does this make any difference?

Hope this helps. Please let us know for future reference..

Reply | Quote

jsher and Andrew – thanks so much but still no joy. To avoid command line switches, I tried running Word from Word.exe in Windows Explorer with same result. Under Tools>Macro>Security>Trusted Publishers (tab) I have “Trust all installed addins and templates” checked ON. There is no other .dot file in C:Documents and SettingsApplication DataMicrosoftWordSTARTUP, and no other addins. Normal.dot has no code in it. Arrrrggh

Reply | Quote

Is the template loading at all? Cross-check the Startup path under Tools>Options>File Locations to make sure it isn’t pointed somewhere funny. I searched Google web and Google groups and didn’t see any other reports of this, but the program’s still just out so… stay tuned.

Reply | Quote

I checked the Startup path – its correct. I put the AutoExec() in normal.dot which is sitting in the …/Templates folder and definitely loading. The *only* thing normal.dot has in it is the AutoExec() , but it still won’t run.

Reply | Quote

What happens if you try changing the name of the macro in Normal.dot to ‘AutoOpen’. That is the one I use if I want to hit every file on opening.

Reply | Quote

When I put an AutoOpen() sub in normal.dot, it runs whenever I open an existing document, but does not run for new document. I guess this is what you expected?

Reply | Quote

If you use AutoNew, to trigger when a new document is created, and AutoOpen, to trigger when a document is opened (this can’t be in a global template), do you really need AutoExec, which runs only when Word starts up?

Reply | Quote

Hi jscher – Yes I need Autoexec because the idea is to create a global addin which, if loaded, will create a button that, when clicked, will run what we call our “namestamp” macro – just a simple little macro that puts the path and name of the document in the bottom left corner of the document. Then we’ll package it (I like your method of doing this which you explained in your “Deploying Word 2000 Templates ” post) and put it on our web site and do a marketing campaign featuring it as a free gizmo. I thought it was going to be easy – sheesh! .

Reply | Quote

Well, it certainly sounds as though something has changed in Word 2003 that no one’s talking about. An alternative method of deployment is a COM Add-in, which can be configured to auto-run certain code at load time. (Or should I say, at least in Word 2000 and Word 2002, it can.)

Reply | Quote

I own a copy of VB6. Do you think a VBA programmer like me could learn to write a COM addin in a reasonable length of time?

Reply | Quote

Yes, if I can do it, you can do it. It tooke me many hours to puzzle out how to use the convenient “designers” (like forms, their code is in a hidden code pane; right-click them in the Project Explorer and and View Code) and to set up event handlers, if needed, but the guts of the project are identical. Creating installers is a bit messy with the Packaging Wizard, but it’s the only thing I’ve used. There have been past posts here on recommendations for others (e.g., Wise, Installshield, etc.).

I found the online help on MSDN a bit sparse. The book “Office 2000 Visual Basic for Applications Fundamentals” was somewhat helpful. Mostly it was trial and error, and a few questions here in the Lounge.

By the way, I used Office Developer edition. There probably are some differences in the more general purpose VB editor in how you start up the project in the first place. MSDN probably covers that.

Reply | Quote

Thank you for your words of encouragement. Do you think that if I write a COM Addin, it is going to be really easy for the end user to install it? That is my chief concern – what if I go through the COM learning curve only to find that it’s still hard to deploy? I have a copy of Office developer edition i think. Thanks for reminding me that I can use it instead of VB. That would be more a more familiar environment than VB6. I’m somewhat disappointed to be going BACKWARDS as I was hoping to work in 2003 and use .NET, but what I read about creating a COM AddIn with .NET on MSDN was truly scary.

Reply | Quote

Deployment of a COM Add-in is via a setup.exe file, so it’s a no-brainer for the user. At least, in an ideal world. I had problems with my Outlook 2000/Windows 2000 add-in not working in Outlook 2002/Windows XP for no apparent reason. Something about different references, I guess, but I just recompiled on the new platform rather than trying to figure it out.

Reply | Quote

Well that’s it then — there’s no option but to, gulp, learn to do a COM add-in. I would cross my fingers but its too hard to type like that.

I’m glad your Outlook 2002/Windows XP recompile was backwardly compatible.

Reply | Quote

…but see also this post.

I essayed with Utils.DLL a couple of years ago, but ultimately came back to Utils.dot for all my Word97SR2/VBA applications.

My main problem was with the installation of an upgraded DLL. The Word applications seemed to drop the reference and not pick up the new reference. Since most of my aps go out locked (so the user can mess up the code more than I have), I could find no easy way of resetting the reference to the new DLL.

I’m back distributing Utils.DOT with my applications.

If you solve the reference problem, please let me know. A utils.DLL would be of use to me in my VB6 projects.

Reply | Quote

…but see also this post.

I essayed with Utils.DLL a couple of years ago, but ultimately came back to Utils.dot for all my Word97SR2/VBA applications.

My main problem was with the installation of an upgraded DLL. The Word applications seemed to drop the reference and not pick up the new reference. Since most of my aps go out locked (so the user can mess up the code more than I have), I could find no easy way of resetting the reference to the new DLL.

I’m back distributing Utils.DOT with my applications.

If you solve the reference problem, please let me know. A utils.DLL would be of use to me in my VB6 projects.

Reply | Quote

Are you sure you have checked Tools, Macro, Security… If it is set High, either set it to Med or Low, or you can always Self-certify. And.. Check the Trusted Sources tab. Trust all Add-ins and templates should be checked. Sorry, havent read this whole thread, it seems to have gone wandering, but the problem is MS has progressively disabled all code since Office 97. We use Security level Med and have started self-certifying with “DeleteThisAndDie”. In reality, abandon all hope. Every 18 months the rug is going to be pulled out from under you.

Reply | Quote

Omigawd! I came back after the weekend and the darn thing works! Could it be I just had to reboot? I swear nothing else has changed. The .dot file is in C:Documents and Settings[Username]Application DataMicrosoftWordSTARTUP, it has a module called “AutoExec” with a subroutine called “Main” and another called “AutoExit”. They are both executing!

Reply | Quote

You do not want to use a module named AutoExec.

Name the module, say, modAutoStuff and have a

Public Sub AutoExec()

in the module.

Reply | Quote

Will you tell me why? It’s working OK right now.

Reply | Quote

Will you tell me why? It’s working OK right now.

Reply | Quote

You do not want to use a module named AutoExec.

Name the module, say, modAutoStuff and have a

Public Sub AutoExec()

in the module.

Reply | Quote

Omigawd! I came back after the weekend and the darn thing works! Could it be I just had to reboot? I swear nothing else has changed. The .dot file is in C:Documents and Settings[Username]Application DataMicrosoftWordSTARTUP, it has a module called “AutoExec” with a subroutine called “Main” and another called “AutoExit”. They are both executing!

Reply | Quote

Are you sure you have checked Tools, Macro, Security… If it is set High, either set it to Med or Low, or you can always Self-certify. And.. Check the Trusted Sources tab. Trust all Add-ins and templates should be checked. Sorry, havent read this whole thread, it seems to have gone wandering, but the problem is MS has progressively disabled all code since Office 97. We use Security level Med and have started self-certifying with “DeleteThisAndDie”. In reality, abandon all hope. Every 18 months the rug is going to be pulled out from under you.

Reply | Quote

Deployment of a COM Add-in is via a setup.exe file, so it’s a no-brainer for the user. At least, in an ideal world. I had problems with my Outlook 2000/Windows 2000 add-in not working in Outlook 2002/Windows XP for no apparent reason. Something about different references, I guess, but I just recompiled on the new platform rather than trying to figure it out.

Reply | Quote

Thank you for your words of encouragement. Do you think that if I write a COM Addin, it is going to be really easy for the end user to install it? That is my chief concern – what if I go through the COM learning curve only to find that it’s still hard to deploy? I have a copy of Office developer edition i think. Thanks for reminding me that I can use it instead of VB. That would be more a more familiar environment than VB6. I’m somewhat disappointed to be going BACKWARDS as I was hoping to work in 2003 and use .NET, but what I read about creating a COM AddIn with .NET on MSDN was truly scary.

Reply | Quote

Yes, if I can do it, you can do it. It tooke me many hours to puzzle out how to use the convenient “designers” (like forms, their code is in a hidden code pane; right-click them in the Project Explorer and and View Code) and to set up event handlers, if needed, but the guts of the project are identical. Creating installers is a bit messy with the Packaging Wizard, but it’s the only thing I’ve used. There have been past posts here on recommendations for others (e.g., Wise, Installshield, etc.).

I found the online help on MSDN a bit sparse. The book “Office 2000 Visual Basic for Applications Fundamentals” was somewhat helpful. Mostly it was trial and error, and a few questions here in the Lounge.

By the way, I used Office Developer edition. There probably are some differences in the more general purpose VB editor in how you start up the project in the first place. MSDN probably covers that.

Reply | Quote

I own a copy of VB6. Do you think a VBA programmer like me could learn to write a COM addin in a reasonable length of time?

Reply | Quote

Well, it certainly sounds as though something has changed in Word 2003 that no one’s talking about. An alternative method of deployment is a COM Add-in, which can be configured to auto-run certain code at load time. (Or should I say, at least in Word 2000 and Word 2002, it can.)

Reply | Quote

Gwenda,

I use a slightly different approach and that works fine on all versions of Word from 97 up.
– Create a module with the name AutoExec
– In that module create a Public Sub Main() which contains all the code you want to run at Word startup.

Regards,
Jan

Reply | Quote

Jan – It didn’t work in Word 2003 but worked fine on an earlier version of Word. Thanks anyway.

Reply | Quote

(Edited by HansV to correct typo in first path and to generalize second path)

> Jan – It didn’t work in Word 2003 but worked fine on an earlier version of Word.

I use Windows XP Pro and Office 2003, both Dutch versions, and my solution works fine on my PC.
I did a little testing and found out that there are 2 Startup directories:
1. C:Program FilesMicrosoft Office 2003OFFICE11STARTUP
2. C:Documents and SettingsApplication DataMicrosoftWordSTARTUP

If the add-in containing module AutoExec with Sub Main is placed in 1 (and Options | File locations is pointing to it) then all works fine, no questions asked. This is the path I actually use. But if I place the add-in in 2 and change Options | File locations to that directory, I get a dialog panel asking if I want the macro’s to run or not. Macro security is normally set to Average on my PC. And if I place the add-in in 1 and Options | File locations points to 2, then I also get the macro security dialog panel. And after granting permission, the code in Sub Main runs…!

So if your add-in is located in 2, you can give relocating it to 1 a try.

Good luck
Jan

Reply | Quote

Jan – I moved the .dot file to C:Program FilesMicrosoft Office 2003OFFICE11STARTUP and then I used Options | File Locations | StartUp to change the StartUp directory to the same path. No joy.

Reply | Quote

Jan – I moved the .dot file to C:Program FilesMicrosoft Office 2003OFFICE11STARTUP and then I used Options | File Locations | StartUp to change the StartUp directory to the same path. No joy.

Reply | Quote

(Edited by HansV to correct typo in first path and to generalize second path)

> Jan – It didn’t work in Word 2003 but worked fine on an earlier version of Word.

I use Windows XP Pro and Office 2003, both Dutch versions, and my solution works fine on my PC.
I did a little testing and found out that there are 2 Startup directories:
1. C:Program FilesMicrosoft Office 2003OFFICE11STARTUP
2. C:Documents and SettingsApplication DataMicrosoftWordSTARTUP

If the add-in containing module AutoExec with Sub Main is placed in 1 (and Options | File locations is pointing to it) then all works fine, no questions asked. This is the path I actually use. But if I place the add-in in 2 and change Options | File locations to that directory, I get a dialog panel asking if I want the macro’s to run or not. Macro security is normally set to Average on my PC. And if I place the add-in in 1 and Options | File locations points to 2, then I also get the macro security dialog panel. And after granting permission, the code in Sub Main runs…!

So if your add-in is located in 2, you can give relocating it to 1 a try.

Good luck
Jan

Reply | Quote

Jan – It didn’t work in Word 2003 but worked fine on an earlier version of Word. Thanks anyway.

Reply | Quote

Gwenda,

I use a slightly different approach and that works fine on all versions of Word from 97 up.
– Create a module with the name AutoExec
– In that module create a Public Sub Main() which contains all the code you want to run at Word startup.

Regards,
Jan

Reply | Quote

Hi jscher – Yes I need Autoexec because the idea is to create a global addin which, if loaded, will create a button that, when clicked, will run what we call our “namestamp” macro – just a simple little macro that puts the path and name of the document in the bottom left corner of the document. Then we’ll package it (I like your method of doing this which you explained in your “Deploying Word 2000 Templates ” post) and put it on our web site and do a marketing campaign featuring it as a free gizmo. I thought it was going to be easy – sheesh! .

Reply | Quote

If you use AutoNew, to trigger when a new document is created, and AutoOpen, to trigger when a document is opened (this can’t be in a global template), do you really need AutoExec, which runs only when Word starts up?

Reply | Quote

When I put an AutoOpen() sub in normal.dot, it runs whenever I open an existing document, but does not run for new document. I guess this is what you expected?

Reply | Quote

What happens if you try changing the name of the macro in Normal.dot to ‘AutoOpen’. That is the one I use if I want to hit every file on opening.

Reply | Quote

I checked the Startup path – its correct. I put the AutoExec() in normal.dot which is sitting in the …/Templates folder and definitely loading. The *only* thing normal.dot has in it is the AutoExec() , but it still won’t run.

Reply | Quote

Is the template loading at all? Cross-check the Startup path under Tools>Options>File Locations to make sure it isn’t pointed somewhere funny. I searched Google web and Google groups and didn’t see any other reports of this, but the program’s still just out so… stay tuned.

Reply | Quote

jsher and Andrew – thanks so much but still no joy. To avoid command line switches, I tried running Word from Word.exe in Windows Explorer with same result. Under Tools>Macro>Security>Trusted Publishers (tab) I have “Trust all installed addins and templates” checked ON. There is no other .dot file in C:Documents and SettingsApplication DataMicrosoftWordSTARTUP, and no other addins. Normal.dot has no code in it. Arrrrggh

Reply | Quote

I don’t have Word 2003 but could it be a naming conflict with another AutoExec macro somewhere? The online help for Word 2002 has this to say…

In the case of a naming conflict (multiple auto macros with the same name), Word runs the auto macro stored in the closest context. For example, if you create an AutoClose macro in a document and the attached template, only the auto macro stored in the document will execute. If you create an AutoNew macro in the normal template, the macro will run if a macro named AutoNew doesn’t exist in the document or the attached template.

Reply | Quote

I tried putting an AutoExec() sub in Normal.dot and it also did not execute. I tried an AutoNew sub and, grrrrrr, it worked – but I need an AutoExec sub because I want to do something everytime Word opens for every document. I set my macro security from High to Medium – no joy. What am I doing wrong?

Reply | Quote

I tried putting an AutoExec() sub in Normal.dot and it also did not execute. I tried an AutoNew sub and, grrrrrr, it worked – but I need an AutoExec sub because I want to do something everytime Word opens for every document. I set my macro security from High to Medium – no joy. What am I doing wrong?

Reply | Quote

I don’t have Word 2003 but could it be a naming conflict with another AutoExec macro somewhere? The online help for Word 2002 has this to say…

In the case of a naming conflict (multiple auto macros with the same name), Word runs the auto macro stored in the closest context. For example, if you create an AutoClose macro in a document and the attached template, only the auto macro stored in the document will execute. If you create an AutoNew macro in the normal template, the macro will run if a macro named AutoNew doesn’t exist in the document or the attached template.

Reply | Quote

s the sub Public?

Reply | Quote

Howard – It is just declared with “Sub”, but Help says: “If not explicitly specified using Public, Private, or Friend, Sub procedures are public by default.”

Reply | Quote

Howard – It is just declared with “Sub”, but Help says: “If not explicitly specified using Public, Private, or Friend, Sub procedures are public by default.”

Reply | Quote

s the sub Public?

Reply | Quote