The Visual Basic Editor (VBE) is the environment where one can write and edit macros. Macros are written in Visual Basic for Applications (VBA), one of a number of coding languages.
You can access the VBA environment in Excel 2011 for Mac by opening the Visual. The Developer tab is the toolbar that has the buttons to open the VBA editor. Hello, i was very happy with using Office 2016 preview but i needed to use migration assistant and after that, it don't work. I still get can't load visual basic for applications message and office crashes. I tried remove based on steps for 'complete removal office 2011' but it still don't work.
Macros are saved inside templates. Within templates, macros are saved in Modules, which hold collections of macros. By default, macros you create go into the NewMacros module in the Normal template. However, you can create other modules within the Normal template, and you can save your macros in other templates if you prefer.
To experiment with modules and macros, you will need to explore the VBE (Visual Basic Editor). You can use simple macros perfectly happily without knowing any of the information that follows. However, this article may help you understand Word a little better, giving you more power over what you do with it. Macros are designed to help you automate Word to make your life easier.
Before You Begin
There is limited undo ability, and no backup here; Word assumes that if you are in this deep you know what you are doing. It would be a good idea to make a copy of your Normal template before you begin playing with macros. Then afterwards you can dump the copy with the macro experimentation and swap back in the older Normal template. For more about the Normal template and how to find it, see here.
It is possible to test macros from the VBE directly. You can run the macro while you are still in the VBE by pressing F5. Make sure the cursor is in the macro you want to test. You can also size the VBE and the Word window on your screen so you can see them both at once, and step through the macro one line at a time, in order to see what it does. Press F8 to begin and to move to each line. (Of course, function keys on a laptop may not behave. F5 is Run>Run Sub/UserForm. F8 is Debug>Step Into.)
If you are going to use Macros a lot, you can use Tools>Customizeto customize the keyboard, menus and toolbars to make switching in and out of the VBE easier. You can also switch between the VBE and Word, and arrange windows to see both at once; you do not need to close the VBE to access Word.
Understanding the VBE
- Start Word and open your Visual Basic Editor from Tools>Macro>Visual Basic Editor. Try not to get thrown by the fact that this puts you straight into an unfamiliar environment; this is a lump of WinWord code that was converted to Mac with as little work as possible to keep the price of Word down. It works — don't expect it to be nice to use.
- You will see a Pane on the top left named Projects. Keep looking until you find it; no other window will do. Users can undock these windows and move them, so be prepared for the fact that they may not be where they usually are.
- At the top of this window you should see an entry named Normal. This is the programmer's eye view of your Normal template. Any global templates that are loaded will also show up in this list, but you cannot manipulate the macros in other templates unless the template is open in Word. The VBE sees each template as a “Project”, and Modules as the items within the Project (hence the Organizer lists modules under Macro Project Items).
- Click the arrow to the left of Normal to expand the tree. You should see a folder named Modules. If you do not see it, the template does not yet contain any macros.
- Select the Normal entry and choose Insert>Module. You must select Normal or Word will add the module to the wrong project. If there was no Modules folder, there will be now.
- Below the Projects window you should now see a Properties window. If you can't, use View>Properties Window to bring it up.
- In the Properties window be sure the Alphabetic tab is the active one. You should see a single item in here: (Name) Module1. Select the name Module1 and type a new name over the top of it. You can call it anything you like so long as the name contains no spaces, for instance, “MyMacros”. Do not call it 'NewMacros'; that is the name Word uses for the place where it saves recorded macros. If you call your folder the same thing, there is a severe danger that the next time you record a macro you will overwrite the one you are installing now.
- Each module will open in its own window in the VBE. At the top right of each window will be a dropdown menu that lists the macros in that module and lets you navigate among them. You can type a Sub MacroName statement directly into the window to create a macro.
You may be interested in a more sophisticated discussion of the VBE here. The page was written for Excel, but the general understanding is similiar.
Organizing Macros
You can transfer modules to a different open template using Tools>Macro>Macros>Organizer. To transfer one single macro, you will need to go into the VBE, and cut and paste the text of the macro to a different template. Or you can create a module that only holds one macro, and use the Organizer to transfer the module. To create a macro in a different template, you have to use the VBE directly, not Tools>Macro>Macros.
Once you get a collection of macros, it’s good practice to move them out of the NewMacros module. That’s because NewMacros is where Word puts macros you record: it’s good to avoid the possibility that you might inadvertently overwrite one of your valuable macros. The simplest way to move NewMacros is to re-name the NewMacros module to something else. Be aware that when you do this, you will have to re-assign your macros to your toolbars or keystrokes, since the full name of the macro includes the name of the template and module that contains it.
A Developer’s Perspective
Generally speaking the differences between Word for Mac and Word for Windows are minimal…at least from the user’s point of view. But if you wish to create cross-platform solutions there are some significant differences for which you must account.
Visual Basic for Applications (VBA) in all versions of Word for Mac is based on Visual Basic (VB) v5. VBA in Word 97 for Windows is also based on VB5, but later versions of Word for Windows use VB6 as the basis for VBA. This means that there are some commands and functions that are available in Word 2000, Word 2002 and Word XP that just are not available on the Mac. Notably these include the Split() Function, and non-modal windows. Both of these are available on Windows (in Word after Word 97), but not on the Mac.
One item that is available in all Windows versions of Word back through at least Word 97, but has never been implemented on the Mac, is the RowSource property for a ComboBox. This lack is not usually a problem unless you use an Excel worksheet as a data source, but you should be aware of it.
All Windows versions have ActiveX controls; the Mac does not. Use the ‘Forms’ toolbar when coding in Windows if you want to share with Mac users. (This applies only to adding controls to a document; UserForms are cross-platform.)
A good starting point for understanding the differences and limitations is the Help in Word X for Mac. Two Help topics in particular give a fairly good overview of some pitfalls to avoid. These topics are:
- Differences Between Word VBA for Windows and Word VBA for the Macintosh
- Strategies for Developing Cross-Platform Solutions
![Mac Mac](/uploads/1/2/5/8/125846100/166669364.png)
If you need to access files, pay special attention to what the second topic has to say about paths and the Application.PathSeparator function; hard-coding file paths will surely fail cross-platform.
While not a design issue, another missing feature on the Mac is the ability to directly export and import items in the Visual Basic Editor. If you have a .bas file from a Windows machine, you can use ‘File…’ on the ‘Insert’ menu to add its contents to a module, but you cannot directly export such files yourself to share with Windows users. You can, of course, copy-and-paste the code into a Word document and save it as text file with the ‘.bas’ extension, and it is possible, using additional code, to export and import forms and modules, but these workarounds are not as convenient as using menu commands, as can be done in Windows.
It goes both ways
Most of the differences are only potential problems when developing in a Windows version of Word, but there are a few that work in reverse, especially AppleScript™. AppleScript is, of course, specific to the Mac, so if you’re developing on a Mac avoid AppleScript, unless you use conditional compilation, and have some way to implement the same functionality in Windows.
Mac programmers who are used to things like CommandButtons (aka PushButtons) and ComboBoxes (aka ListBoxes) not being able to ‘take focus’ should be aware that they can in Windows, and also that a UserForm on a Mac will behave the same way. This means that users can ‘tab’ from one control to another, including buttons, and then hit the Return key to activate that button or control. You can set the control’s .TakeFocusOnClick and .TabStop properties to false to disable this on either platform. This same functionality is now available with Mac OS X, so it may not be completely foreign to Mac users, but it’s still new enough to not be ‘second nature’ to most Macophiles.
Developers not immune to Other Differences
Some of the same differences that affect users will also affect you as the developer. The menu structures are very similar, but not identical, so you if you wish to add CommandBars in the menu, you’ll want to use CommanBars.FindControl to be sure you’re at the correct menu item.
Font and display/resolution differences can also be an issue, especially when creating UserForms, but they will also affect templates (see other topics at this site for more information about ways to design documents that can be shared).
A UserForm carefully crafted to look perfect in one environment will almost certainly not look the same on the other platform. The default font for Windows UserForms is Arial, and for the Mac it’s Geneva. However, even if you specify a font that you know is on both machines, it will still be displayed differently. You can minimize some of this by assuring that all items with captions have ample room for the caption so the text won’t be truncated when moving from one arena to the other.
Two versions?
Unless you absolutely cannot ‘code around’ differences, maintaining a Windows and a Mac version of your solution should be a last resort. Conditional compilation is a powerful tool for avoiding certain problems.
If you have a UserForm that you just can’t seem to make look right on both platforms, consider using two otherwise identical UserForms (the only difference being the names of the UserForms themselves; all controls would have the same names), one tweaked for Windows, the other arranged for the Mac. You can then Show the appropriate one based on which system is running, and use shared code (in a module) so there is only one code base to maintain. For example, in a Module, you would have this code:
The individual UserForms must both have a textbox named TextBox1, and in the UserForm_Initialize() Event for each UserForm, you would do this:
Use a similar technique for any other controls that require code.
Additional Help
Most of the other FAQ items and topics on this site apply equally well to Mac and Windows, as long as you are aware that there are differences and adjust the code examples accordingly.
If you can’t find your answer here or in Help, there are several Word newsgroups available on the microsoft.public news server. These include (but are definitely not limited to):
- microsoft.public.vba.addins
- microsoft.public.vba.beginners
- microsoft.public.vba.general
- microsoft.public.vba.userforms
- microsoft.public.vba.authoring
- microsoft.public.mac.office.word
As always when posting to such groups, remember to include your platform (Macintosh!), OS version, and Word version, or the respondents may not be able to answer.