Visio and VBA -- PART - I - AuthorKen Getz and Mike Gilbert

What is VBA, anyway?
VBA: "Freedom from the tyranny of idiosyncratic macro languages"

Visual Basic for Applications (VBA), is a cross-product programming language and environment. The current version (5.0) appeared first in Microsoft Office 97, and has been licensed by over 50 software vendors throughout the world. Because the product includes both the language engine and the integrated development environment (and Microsoft forms, as well), using it in one product "feels" the same as using it in another. Figure 1 shows the VBA environment (started from Microsoft Word) in use.

Visio was the prime company, outside Microsoft, to completely incorporate the VBA 5.0 development environment and programming language into an off-the-shelf application. By adding this standard programming language/environment, the millions of Microsoft Office 97 users can realize immediately at home in the Visio development environment, because they’re one and the same.

The VBA development environment.

One exception: because of the architecture of Microsoft Access, this one product was unable to switch to the complete VBA 5.0 IDE. All of the information presented here applies to Access, with the exception of the section covering Microsoft Forms. Access’ native forms are more powerful than the modal dialog boxes available as part of Microsoft Forms, so the Access team kept their own forms in that one product.

One more: Outlook 97 includes VB Script, not VBA. Future versions of Outlook should include the full VBA product. Deadlines are deadlines.

When VB? When VBA?
There’s a thriving development community, writing add-ins for Visio in Visual Basic. Now, Visio’s "upped the ante": they’ve included the programming language in the box. How does this affect you, if you’re currently providing add-ins or tools for Visio in Visual Basic?

Think Ragu®
If you haven’t got a copy of Visual Basic, now you don’t need one in order to write Visio applications and add-ins. The language and programming environment come with the product, so everything you need is there, in one place.

Conjoined Twins, if you will
No matter how you worked it out, calling Visual Basic applications from Visio caused your add-in to run in a separate process, and a separate memory space, than Visio itself. Working this way can be quite slow. VBA runs in the same process as its host, so you no longer pay the penalty of working in a separate process.

A Very Tight Mix
Because VBA integrates directly with Visio, in its memory space, it can communicate much more closely with the running VBA code than it could with your Visual Basic add-ins. For example, it’s now easy to attach code to events of documents and shapes.

Distributing the Goods
As a by-product of the way Visio stores your VBA code, the code always exists as part of a Visio document. That way, the code "lives" with your drawing. There’s never an issue, worrying whether the user has installed your add-in or tool – it’s always there!

Never Travel without Protection
Some skeptics will complain: they used to be able to hide their code by compiling it into VB or C executables. How will they be able to keep users out of their code, if it’s right there in the drawings? The answer is code protection. You can password-protect your code, so only developers who know the password can get in and muck with it. Check out the Tools|Project Properties|Protection menu item for more information.

The Big Event
Because VBA is so tightly tied in with Visio, it’s really easy to attach code to events as they occur. For example, if you wanted to ensure that every shape dropped onto your document included some text, you might write code like this:

Private Sub Document_ShapeAdded(ByVal Shape As Visio.IVShape)
With Shape.Characters
If .CharCount = 0 Then
.Text = "Visio Rules!"
End If
End With
End Sub

This way, every time a user drops a shape onto the document, Visio calls this chunk of VBA code, passing in a reference to the shape that was just dropped. You can use that reference in order to work with the shape, programmatically.

Look What You Get For Free!
Because VBA is tightly integrated with its host, whether the host is Visio, Excel, or any other product, your code always knows its context. Therefore, although Visio provides an Application object, you needn’t worry about it, if you’re writing code in a Visio VBA project. In addition, all the active objects have built-in references. For example, ActiveDocument, ActivePage, and ActiveWindow are all ready for you to use in your solutions. It’s easy to grab the object you need and start programming!

One at a Time, Please
For better or for worse, because each application hosts VBA in its own process space, if you run multiple applications that host VBA concurrently, you’ll end up with multiple VBA sessions. Therefore, if you’re running Visio and Excel, and press Alt-F11 in each (that’s the magic key that brings up the VBA environment), you’ll end up with two copies of VBA running. Is this a good thing? You’ll have to decide for yourself. It’s just the way it is.

It’s Modal or Nothing
Microsoft Forms (the forms that are available as part of VBA) are modal. Period. (At least, in this version of VBA – we’re hoping for some sanity in a future version.) This does mean, of course, that some types of wizards and add-ins will still need to be written in Visual Basic, or other languages. If you want your form to interact with a user’s drawing, allowing the user to switch back and forth, you’re out of luck if you want to use Microsoft Forms to build your interface.

PART - II Click here