DAVSL Architecture
Home Visio  DAVSL Main  This page

Starting Point

The main references for VSL structure and behavior are:

Since I won't have the chance to rehash everything in those sources, you will definitely want to at least be familiar with what is to be found in them.

That said, here's a quick overview.

Naive View of VSL

At first glance, VSL structure looks like the following diagram:

Visio has defined an entry routine (VisioLibMain) which the DLL must export, and in addition a variety of messages that Visio can send to the VSL. The most important message is RUN, which of course is what Visio calls in response to a RUNADDON ShapeSheet function, or for UI objects that specify an AddOn call as their action. In a RUN message Visio passes a string containing any parameters that are provided (say in RUNADDONWARGS).

 In addition, there's the capability for the addon to call-back to Visio via a special callback address for certain special purposes.  And finally, almost always your addon will be using the usual OLE Automation mechanism to control and manipulate Visio, drawings, shapes and so on.

Note the important feature that a single VSL can and often will house more than one AddOn.  Implications:

More Sophisticated View of VSL

As noted above, as a single AddOn corresponds to only one of possibly several related functions you might want your VSL to provide, it makes some sense to implement this internally with a single object with multiple methods. Then the individual AddOns function as interfaces to the methods. This is diagrammed below:

Notice how each AddOn (XXX_A, XXX_B, XXX_C) really does nothing but act as an interface to the A, B and C methods on the XXX_Controller object (an object that knows how to take care of XXX functionality, we assume).

But then why even bother with the AddOns at all? Because Visio requires that each AddOn not only respond to RUN, but also provide information about itself (name, in what context to be enabled and so forth).

Design Tensions

Because the correspondence between AddOns and a VSL's internal objects is a little bit of a misfit, the exact way to partition the functionality is not a foregone conclusion. In fact, there's nothing to stop you having only a single AddOn, and distinguish the function required by way of an argument, say Func=ThisFunction or Func=ThatFunction.

One consideration is whether you want the individual functions to be visible in the AddOns menu, a context in which Visio can't supply arguments (and hence couldn't support sending a Func=XXX argument). This is not very important to end users, but may be significant to fellow developers or during debugging.

Implementation in DAVSL

The following diagram shows a semi-detailed view of how the above model is implemented in DAVSL:

DAVSL provides a generic DPR Project file for you to copy, which provides the basic definition of the VisioLibMain entry point. No need to edit this file other than to change name.

DAVSL also provides the VSL object, which essentially handles dispatching Visio's messages to the correct message methods within the correct AddOns. No editing required of this DAVSL unit, just include it in the project.

You provide one or more units providing AddOn objects (inheriting from TAddOn) and implementation of the actual functionality you want. TAddOn , provides default handling for some messages, such as ENUMADDONS and RUNABOUT, significanly reducing how much you have to know or do to get started.

The diagram above shows the AddOn objects separate from XXX_Control object (likely in a separate unit), which is often a desirable partitioning, especially if you may want to use the XXX_Control in a non-VSL project.  However, if you are creating a very simple VSL, then you can dispense with a separate XXX_Control object and put the logic into the AddOn object(s) themselves.

The supplied examples show several variations on these themes.

Article Created: 2000-09-20  Last edit: Last edit: 00-10-30 Graham Wideman
Go to:  DiagramAntics.com