GWVisio_Demo: Initial Design Decisions

Last edit: 05-03-17 Graham Wideman

Visio + Delphi

GWVisio_Demo: Initial Design Decisions
Article created: 99-02-01

VSL or Stand-Alone Controller?

You can build your Visio Automation Controller ("Automation Client") as either a "VSL" or as a stand-alone program.

VSL:

Basically a DLL that you stick in a particular Visio directory, and which Visio loads on demand.
Must implement a few Visio-defined functions so that Visio can initiate communication with it.
All other communication can occur via OLE Automation and via a couple of different events mechanisms.
Operates in same process space as Visio, so interaction is not slowed by communication crossing between processes.
Generally the way to go to achieve good integration with Visio.
Possible disadvantages: Crash in VSL crashes Visio too, since in same process space.

Standalone Program:

A "normal" xxx.exe OLE Automation Controller, with one of two events mechanisms if needed. Testing and debugging a standalone controller can be a little easier.

So, for simplicity, the demo is a stand-alone application.

Type of Interface (ie: You Choose When References are Resolved)

Automation Controllers use variables to reference OLE objects within the automation server (in this case Visio), such as Application, Document, Page, Shape, Cell and so forth. OLE defines three distinct approaches for this, each with advantages and disadvantages:

Approach:	Advantages	Disadvantages
OLE Variant: The controller's variables are declared as OLE Variants, and each method or property reference is resolved at run time.	No need to work with Type Libraries.	Compiler can't check your references -- frequent source of bugs won't be checked until runtime. In addition, resolving references at runtime is slow.
"dispinterfaces"	Faster than OLE Variant	Slower and not as smart as "interfaces"
"interfaces"	Resulting app is faster. Code is cleaner. Makes maximum use of compiler's ability to check your references.	You have to use Type Library with Delphi -- can you click a couple of buttons?

Needless to say, this example uses interfaces and employs Delphi's Type Library features.

Event Handling Approach

Visio offers two different ways for a controller to get notifications of events, which I'll call the "ConnectionPoint" and "AddAdvise" approaches.

Approach	Advantages	Disadvantages
Connection Point: Controller basically registers for all available notifications. Controller's event-response code decides which notifications to actually do something about.	Simple to code.	Every available event results in a notification call from Visio to controller. Because this is potentially time consuming, there are some events that Visio doesn't offer this way -- they are available only through the AddAdvise method.
AddAdvise: Controller registers only for the exact events it wants to see.	Visio doesn't waste time calling controller for events that are not of interest. Some events are only available by this method.	Since this is a less orthodox approach, code to do this is not widely available, and the translation from Visio's C++ example is tricky. (This example shows how.)

This demo shows how to use the AddAdvise method.

If you are interested instead in the Connection Points method, see Binh Ly's excellent info and code generator, here. I've tried it on Visio and it indeed works.

For info events is covered in detail in the Visio Automation Reference help file, and my book provides a convenient tabulation and cross-reference of which Visio objects can report events concerning which other Visio objects .

[Back to: GWVisio Demo for Delphi]

Go to: Up to: [Visio]