VBA for Mac Word vs. Word for Windows

Article contributed by George Clark

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:

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:

Sub Initialize(uf As UserForm)
  uf.TextBox1.Text = “Hello”
  ‘ any other items that need to
  ‘ be set up, prefixing all controls
  ‘ with ‘uf.’
End Sub

The individual UserForms must both have a textbox named TextBox1, and in the UserForm_Initialize() Event for each UserForm, you would do this:

Sub UserForm_Initialize()
  Initialize Me
End Sub

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):

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.

Return to Top