Visual Basic for Applications is an implementation of Microsoft's event-driven programming language
Visual Basic 6 and its associated integrated development environment.
Visual Basic for Applications enables building user-defined functions, automating processes
and accessing Windows API and other low-level functionality through dynamic-link libraries.
It supersedes and expands on the abilities of earlier application-specific macro programming
languages such as Word's WordBasic.
It can be used to control many aspects of the host application, including manipulating
user interface features, such as menus and toolbars, and working with custom user forms
or dialog boxes.
As its name suggests, VBA is closely related to Visual Basic and uses the Visual Basic
Runtime Library, but it can normally only run code within a host application rather
than as a standalone program.
It can, however, be used to control one application from another via OLE Automation.
For example, it is used to automatically create a Word report from Excel data, which are automatically
collected by Excel from polled observation sensors.
VBA has the ability to use DLLs, and later versions add support for class modules.
VBA is built into most Microsoft Office applications, including Office for Mac OS X and other Microsoft
applications such as Microsoft MapPoint and Microsoft Visio, as well as being at least
partially implemented in other applications such as ArcGIS, AutoCAD, CATIA and WordPerfect.
Design Code written in VBA is compiled to a proprietary
intermediate language called P-code, which the hosting applications store as a separate
stream in COM Structured Storage files independent of the document streams.
The intermediate code is then executed by a virtual machine.
Despite its resemblance to many old BASIC dialects, VBA is incompatible with any of
them except Visual Basic, where source-code of VBA modules and classes can be directly
imported, and which shares the same library and virtual machine.
Compatibility ends with Visual Basic version 6; VBA is incompatible with Visual Basic .NET.
VBA is proprietary to Microsoft and, apart from the COM interface, is not an open standard.
Automation Interaction with the host application uses
OLE Automation.
Typically, the host application provides a type library and application programming interface
documentation which document how VBA programs can interact with the application.
This documentation can be examined from inside the VBA development environment using its
Object Browser.
Visual Basic for Applications programs which are written to use the OLE Automation interface
of one application cannot be used to automate a different application, even if that application
hosts the Visual Basic runtime, because the OLE Automation interfaces will be different.
For example, a VBA program written to automate Microsoft Word cannot be used with a different
word processor, even if that word processor hosts VBA.
Conversely, multiple applications can be automated from the one host by creating Application
objects within the VBA code.
References to the different libraries must be created within the VBA client before any
of the methods, objects, etc. become available to use in the application.
This is achieved through what is referred to as Early or Late Binding.
These application objects create the OLE link to the application when they are first created.
Commands to the different applications must be done explicitly through these application
objects in order to work correctly.
VBA code written in Microsoft Access can establish references to the Excel, Word and Outlook
libraries; this will allow creating an application that runs a query in Access, exports the results
to Excel, formats the text, then writes a mail merge document in Word that it automatically
e-mails to each member of the original query through Outlook.
VBA programs can be attached to a menu button, a macro, a keyboard shortcut, or an OLE/COM
event, such as the opening of a document in the application.
The language provides a user interface in the form of UserForms, which can host ActiveX
controls for added functionality.
Security concerns Like any common programming language, VBA
macros can be created with malicious intent.
Using VBA, most of the security features lie in the hands of the user, not the author.
The VBA host application options are accessible to the user.
The user who runs any document containing VBA macros can preset the software with user
preferences.
End-users can protect themselves from attack by disabling macros from running in an application
or by granting permission for a document to run VBA code only if they are sure the source
of the document can be trusted.
Development As of July 1, 2007, Microsoft no longer offers
VBA distribution licenses to new customers.
Microsoft intended to add .NET-based languages to the current version of VBA ever since the
release of the .NET Framework, of which versions 1.0 and 1.1 included a scripting runtime technology
named Script for the .NET Framework.
Visual Studio .NET 2002 and 2003 SDK contained a separate scripting IDE called Visual Studio
for Applications that supported VB.NET.
One of its significant features was that the interfaces to the technology were available
via Active Scripting, allowing even .NET-unaware applications to be scripted via .NET languages.
However, VSA was deprecated in version 2.0 of the .NET Framework, leaving no clear upgrade
path for applications desiring Active Scripting support.
Support for VBA in the Mac OS X version of Microsoft Office was dropped with the release
of Microsoft Office 2008 for Mac.
The official reason given was that VBA relied heavily on machine code written for the PowerPC
architecture, and that rewriting this code for dual PowerPC/Intel architectures would
have added another two years to the development of the suite.
However, the Office suite can be automated via AppleScript to an extent.
VBA was restored in Microsoft Office for Mac 2011.
Microsoft has clearly stated that they have no plans to remove VBA from the Windows version
of Office.
With Office 2010, Microsoft has introduced VBA7 which now contains a true pointer data
type: LongPtr.
This new data type allows referencing 64-bit address space.
The 64-bit install of Office 2010 does not support common controls of MSComCtl or MSComCt2
so legacy 32-bit code ported to 64-bit VBA code that depends on these common controls
will not function.
The 32-bit version of Office 2010 is unaffected by this issue.
VBA7 includes no 64-bit version of the common controls, so it leaves developers with no
means to migrate VBA applications to 64-bits.
Microsoft suggests contacting the software vendor for 64-bit versions of VBA controls.
Visual Studio Tools for Applications
See also Visual Studio Tools for Office
Microsoft Visual Studio Microsoft FrontPage
References