共用方式為

Dev Luv: Programmability for the Visio Engine Versus Visio Solutions

  • 發行項

A common question that I’ve seen on the Visio developer newsgroups asks for more information on automating the UML or Database Modeling functionality. There is no published automation model for UML or Database Modeling, which tends to puzzle most developers since there’s quite a bit of programmability support for other aspects of the Visio application. Likewise, there’s no API for the Organization Chart or Timeline solutions, although both do have a command-line interface that you can use for some automation.

This lack of automation support for some parts of Visio is neither arbitrary nor an oversight. Visio is actually more than just a single application in a box. Visio consists of an drawing and rendering Engine, and a number of solutions that we have built internally to use the engine to do things like create org charts and model databases.

 

The Engine itself has a rich API and is well-documented with an extensive SDK. The Visio engine API has to be rich and robust because our own solutions are built on top of it. A little known fact: Every code-driven solution that you access through the Visio Shapes menu uses the documented Engine API. That means our own internal Visio solution developers use the same API that third party Visio developers use. Along with the testing that we do directly on the automation layer before we release a new version, every solution in the Visio box also exercises the API thoroughly before it goes out to customers.

 

Every release, we get a long list of automation enhancements, the majority of which comes from our own internal solution development. The Visio solutions that we ship in the box include some hard-core applications. The Database Modeling solution is the most complex of the solutions, followed by Organization Chart and UML. These solutions contain thousands of lines of code. It constantly pushes the Visio API to be more flexible, more performant, and more stable. It also means that we have a pretty complex event model, which will be the subject of the next several developer blogs.

 

But while we document, support, and extend the Engine automation layer, we do not publish any of the solution APIs. The only exception to this rule is the two command-line interfaces that we publish for the Organization Chart and Timeline solutions. There are two main reasons for the rule of not offering an automation layer for solutions. One, we want third-party developers to extend the Visio Engine and not the solutions that we build on top of it. Two, our focus in product development is to make the Visio Engine automation better and not to divert our resources against publishing and supporting dozens of solution APIs.

 

So what does this mean to you as a Visio developer? When you’re planning and designing a Visio-based solution, start thinking about Engine versus solution behavior. Is what you’re trying to automate functionality that can be done in any drawing using the Visio toolbars and menus? That’s Engine functionality and well-supported. Or are you trying to extend or customize the functionality that you see in the Database Modeling solution and can’t be done in another drawing? That’s solution-specific and we don’t provide an automation layer for it. Since the Database Modeling solution was built on the Visio automation layer, you can replicate the functionality yourself, but it’s going to be some work. Instead, look for ways that brings you back to customization on top of the Visio Engine – you’re going to save yourself a ton of work that way. Not only is Engine customization supported by docs and an SDK, it’s also where we on the product team focus our resources for the next release – extending that functionality, making it faster, and fixing any bugs we find along the way.

 

 -- Mai-lan

 

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments