I have a VBA project provided by my company. It is password protected and I cannot add new modules to the project nor can I have a second one open at the same time.
Could I either remove the password from that VBA project, have a second project open at the same time, or still run my own custom macros at the same time?
I basically want to use the company macros as well as my own.
You can't have multiple VBA projects opened at the same time. But you can have multiple modules opened, imported and exported. So, following that way with modules you can have both solutions working in Outlook.
As I already wrote, Outlook support only one VBA project at a time. On the other hand, one can select, which of all possible VBA projects should be used at start. VBA project is saved in separated OTM file, located at %appdata%\Microsoft\Outlook.
To start other VBA project than default, one has to enable this option, a corresponding registry value is listed below:
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Security\EnableAltVba
It has to be set to 1) and then after Outlook can be started with command line switch
Outlook.exe /altvba \\MyServer\MyShare\otmfilename.otm
Related
I created two macros in Outlook's VB and I want to pass them on to others where I work. Is it possible to do this without copying the code to each account individually? Is there a way to export my project (or my modules) and import it into another account so that the macros I wrote will be added automatically?
Another option for me is whether it can be done in a small program written in C# (i.e. Console Application) with the Outlook namespace.
If you're developing a solution that you intend to distribute to more than a few people, you should convert your VBA code into an Outlook COM or VSTO add-in or an Office add-in for Outlook. However, developing an add-in typically requires considerably more programming knowledge than creating a short macro. If your VBA project is relatively simple, and there aren't too many people that have to use it, you may want to distribute the code together with instructions to set it up.
The easiest solution is to right click on ThisOutlookSession and choose Export File. You'll need to do for each module (if any) in your Project.
Unlike other Microsoft Office programs, Outlook supports only one VBA project at a time. VBA macros are stored in a file that's named VbaProject.OTM. This file is a product storage file and isn't meant for distribution. Outlook doesn't provide a direct means to manage OTM files. Outlook VBA code wasn't designed to be deployed or distributed. It was designed solely to be a personal macro development environment. The project, Project1, is available and associated with the program at all times. It's not possible to add another project in the Visual Basic Editor.
Project1 is stored on your hard disk as VbaProject.otm in the following folder:
<Drive>:\Users\<LogonName>\AppData\Roaming\Microsoft\Outlook
If you want to begin a new VBA project, you could theoretically export all your existing modules and forms. But this is typically not a realistic approach. Instead, follow these steps:
Exit Outlook.
Locate your VbaProject.otm file in the indicated path.
Rename the file to something meaningful to you, such as VbaProject-testing.otm.
Restart Outlook.
Because Outlook can't find an existing project file, Visual Basic Editor starts with a new project. When you save changes to your project, Outlook creates a new VbaProject.otm file in the folder. If you want to switch between projects, add one more step to the previous procedure (as step 4):
Exit Outlook.
Locate your VbaProject.otm file.
Rename the file to something meaningful to you, such as VbaProject-testing.otm.
Restore the name the file that you now want to use as VbaProject.otm.
Restart Outlook.
If you want to move a VBA project from one computer to another, first determine where Outlook is storing the VbaProject.otm files on each computer. Then, copy the OTM file from one computer to the other, and make sure to put it into the correct folder. When you restart Outlook, the program will find the VbaProject.otm file and use it.
You may find the How to backup and save your Outlook VBA macros article helpful.
I seek advice on how to manage userdefined VBA-functions that are used in several workbooks:
Background:
Over time i have created several Excel workbooks (wbs), each with a slightly different purpose, that are ultimately based on a library of my userdefined functions and class modules (From now on: library). The "master"-versions of the wbs are revision-controlled. The wbs are used by several people.
However, I do not use an addin for the library, and hence the modules and class modules are actually locally present in each wb's specific VBA project. This makes it a nightmare when doing either expansions or corrections, as I have to revisit and implement said alterations in each wb.
Furthermore, in each wb there are unique functions, understood such that those are not intended to be shared. Those functions, however, might utilize the library-functions.
Main-Question: How should one manage vba functions across several workbooks shared by several users?
My considerations/Sub questions:
Should I convert the library to a true addin and discard the local copies in each wb?
How do I tell the users that the add-in is required upon getting a copy of the maser-version?
How does one cope with legacy/local versions/branches that are spread among the users? Both current legacy copys and future legacy copies that might be used for reccuring tasks?
Where should such an addin-in be stored (in a shared folder or something)?
Would it be considered "bad practice" to force load the add-in using the workbook_opensub?
Any advice or guidance in best practice is appreciated.
Edit: I have tried to highlight the main question, please consider the sub questions as my own thoughts on the subject.
Until recently, I had several add-ins that lived on a shared drive. I had the users install the add-in using File - Options - Addins and wrote up the instructions to do it. The copy on the shared drive was read-only. For changes, I would code and test on the dev copy on my machine, then deploy it to the shared drive. The next time the user started Excel, the changes would be there.
Then we wanted more people to have the addins and not all of them had access to this shared drive. Also, people complained when they were off the network that it still tried to connect to the addins. So we went a different route.
We used a program called PDQ Deploy to put the addins in everyone's addins directory, so they had a local copy. We also deployed a script that copied the files from a company-wide shared drive to their addins directory. If they weren't connected to the nextwork, the script would fail silently. Finally, we used group policy to 1) create the registry entries to install the addins and 2) create a scheduled task that kicked off the script every night. Updating every day is overkill, but the files are only a few kbs, so we went with it.
Now I can deploy new versions to the company-wide shared drive and everyone will have the changes the next day (or the day after they're back on the network).
I put my vba stuff on the "personal" workbook (Windows menu : Unhide...) and whatever workbook I am using I can use them from there.
You do have to make sure about knowing which one is acrtive though...
Hi I am just trying to create an addin which can create and run macros. And are there ways to enable the developer ribbon automatically using Addins?
What I am basically looking at is to create a clean way to do all of the above without getting the people who might use the macro going through all the developer's procedures.
After searching for long I just found one article regarding distribution of macros, which didn't mention any specific programmatic way of automating all this.
Article on distributing macros!
Any help would be greatly appreciated.
Thanks guys..
As far as I could find, the scripts cannot be easily created and pushed into Outlook using addins (which is more or less like hosting a web app and opening inside Outlook).
The solution that I came up to my problem was
1) To use a batch file to create the script as .txt file as per the requirement of the user and then renaming the generated .txt file as .bas file at the end of the batch file itself, then importing the bas file from Outlook's VBA editor.
3) The Outlook VBA editor can be opened easily using the shortcut alt + F11.
4) The bas file can be then imported from File options.
5) Create a new Rule with the condition to run the script.
I want to make an excel file which would do the following steps:
Delete all the excel files from the downloads folder except for the one latest downloaded file.
Make a copy of that excel file names as "Data.xls" and system makes a "Beep" sound
Repeat the above mentioned two steps every 15 minutes
I can do this in Visual Basic but unable to implement that in Excel Macro...
Please help.. My promotion depends on that :-)
Set a reference to the Microsoft Scripting Runtime. The images below shows the classes available in the Object Browser. I usually use this for file-related tasks in VBA. I did some research & the Microsoft Scripting Runtime is standard on Windows so everyone should have it
I created a VBA-macro which will be used by some word-documents within my company. The macro detects tags and removes chapters from a document. This document is created by another program. So the macro should be separately distributable.
Is it possible to generate an executable which adds the macro to the user running the executable?
Is there another way to package macros and install them on a user's computer?
Thanks
The easiest way to deploy Macros is via a template. Create your Macro and save the file as .dotm (macro-enabled template). I think you will get a suggestion where to save your .dotm-file.
Any colleague who wants to use your template simply has to put it in that directory (I think it's C:\Users\[UserName]\AppData\Roaming\Microsoft\Templates). After that, he should be able to use the macros while working on any word document.
There are basically five ways to do this:
1) Send everyone a text file with your macro that they can paste into their own Normal template. This is fine for very simple macros that are unlikely to have any name conflicts with macros users create themselves, but it does require basic knowledge of the VB editor.
2) Send everyone a .bas file that you create by exporting a module that contains your macro(s). This gives you a little more control and avoids copy/paste errors. Still requires basic understanding of the VB editor (or decent instructions from you).
3) Package your macros in a template (.dotm file) that lives in the Templates folder. Users can apply that template to any document they're creating and gain access to your macro(s). No VB knowledge required; this is done through the standard Word New File process. Also allows you to include styles or other things if you want.
4) Package your macros as a global template (.dotm file) that lives in the Startup folder. Users will have access to your macro(s) in every file they work on, no need to apply your template. This is good if what you are doing is central to your team's workflow and doesn't require that you include styles with your macro. You can also build in UI elements. (There can be issues with this approach in Word 2011; users may not have immediate access to the global template but it is easy enough to get back.)
Both 3 and 4 do require that the user initially place the .dotm file in the right place. You can help them with this (one approach is to use another Word doc as a "setup" file that, when run, places the template in the presumed correct folder). Obviously that requires more work on your part so how far you'd want to go with that depends on you and your business needs.
5) Additionally, if you have control over the creation of the document itself (rather than just the macro) you can embed a macro in the document. You can place the macro itself in the document's ThisDocument module (find your document in the Project Explorer and then open Microsoft Word Objects). Then save the document as .docm (macro-enabled document). Users should be instructed to enable macros when they open the document (different versions of Word use slightly different interfaces for prompting the user about this, but it's always pretty obvious).
Over the last 7 years I have been deploying my Word VBA in a different way. The software is a Word add-in that makes it easier for teachers to provide feedback on assignments. It is distributed as a 30 day trial and if the user buys it they are given a key which enables them to use eMarking Assistant for a year. You can test the deployment system at http://eMarkingAssistant.com
The deployment and licensing mechanism is given below:
save the vba in a macro enabled document i.e. a .docm file
in Windows rename the file to be a .doc file
use Orlando's excellent "VBA decompiler and compacter" from http://orlando.mvps.org/VBADecompilerMore.asp to remove compiled code and references to specific Office versions from the .doc and compact the document
ask the user to download the .doc file
ask the user to open the .doc file and ensure that macros are enabled
let the user trial the software in the document
if they want to use the software in any document they click an "install" button in the document to copy the vba code to to a .dotm file in their Word startup folder (so it is loaded automagically)
if they want to buy a subscription to use the software, they pay using paypal and I send them a key which unlocks the software until the end of the subscription
Advantages of this process are:
a single document can be used on all versions of Office for Windows from Office 97 to Office 2016 (32 bit and 64 bit).
the install and uninstall all happen within Office so the suer does not need to admin rights over their computer
users do not need to install the software until they have used it in the document
users do not need to use another program to unzip or install the software
Peter Evans