VBA, Add-in or Add-on?

[Ramone]

Hi. I am about to start my first Visio project (business process modeling
tool) but don't have the experience necessary to decide whether I should
code via VBA, Add-in or Add-on. So hopefully, someone can help me out.

I have read "About Microsoft Visio Add-ons and COM Add-ins"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvisio02/html/visaddin.asp
but it hasn't pointed me to one architecture or another.

The plan...
- drawings will contain 200-1000 shapes (40-200 groups) from a 30-shape
stencil already created
- drawings will take care of the visual aspects of the business process
while a database will store all the logic (activities, decision points,
resourses used, etc.) so that I can write code to do statistical analysis
and reporting.

I need to be able to...
- add a menu to Visio
- navigate between drawings (drill-up/drill-down on specific shapes)
- open tabbed forms to edit attributes of shapes, everytime I drag and drop
a shape in a document or right-click on a shape already added. These
attributes will be chosen from existing database values or create new DB
entries
- group shapes together if one is dropped on top of another (and make
appropriate DB changes)
- support complex rules of which shapes can be interconnected (type,
cardinality, directionality)
- modify shapes (text, color, size, position, etc.) based on properties that
the user changes
- run code to check that everything in the drawing conforms to rules I have
setup (e.g. no arrows unconnected, no orphan nodes, etc.) and that there are
no conflicts between drawings (DB values)

My concerns are...
- speed
- ability to hide the source code
- centralization of the code (don't want old code in old drawings)
- ease of programmability (I have a good grasp of VBA but don't know about
any Add-in/Add-on complications)

So, my question remains: should I proceed via VBA, Add-in or Add-on? Any
help would be greatly appreciated!

Ramone

 

[Chris Roth [ Visio MVP ]]

VBA is great for prototyping and for speed, but get's icky with the whole
"lives in the document" thing. Of course you can put the VBA in an auxiliary
document (like a stencil) that is required while the user is drawing. If the
stencil is open, then the code can be accessed.

You might also try using the Visio Active X control, in which you basically
plop a Visio control on a form. This is great for limiting functionality,
but then you need to add a few rudimentary UI elements like File, Save,
Zoom, Connector tool, etc. yourself.

A COM Add-in can be created with VB, and it integrates fairly well with
Visio, but it's not as easy to call the code as in VBA.

Tough call, hopefully some others will comment as well. If you're positive
you'll be staying in the VB6 world, then it won't hurt too much to
prototype/get started with VBA.

--

Hope this helps,

Chris Roth
Visio MVP

 

[Al Edlund]

I agree with Chris that VBA is great for prototyping and then moving on to
whatever platform you might want. The other nice thing about this is to use
v2003's ability to copy/create macros for getting at code that might not be
readily obvious when manipulating visio objects. Graham Wideman discusses
this material as well as VSL's in his book Visio 2003 Developers Survival
Pack, which although not bedside reading is an absolute must if you're
serious about visio solutions.
Al

 

[Ramone]

Thanks for the input! I will most likely build an Add-on but use VBA for
prototyping, as you have both mentioned.