×

AutoCAD

Embedded versus DVB Files

31 Oct, 2002 By: Bill Kramer

---

Visual BASIC for Applications (VBA) developers have two choices for the storage of their macros. They can store the macro as a DVB file and load it using the VBALOAD and VBAMAN commands. They can also store the macro in the drawing as an embedded macro. Each option poses some interesting advantages and it is up to the programmer to determine what works best. Additionally, each option has some distinct disadvantages.

In this column I will be looking the good and bad for each option as well as sharing some hints towards ways to work around some of the bad items.

Just so we have our terms in order, let's agree upon the following:

• A project is a place to store macros.
• The macros are the enhancements we are adding to AutoCAD and are created by defining public subroutines that have no parameters.
• In order to run, a macro must first be loaded in the drawing, and then the VBARUN command used to initiate the macro.

The load and run sequence can be added to a menu button or activated inside a Visual LISP function.

Embedded Project
An embedded project is where the macros are stored in the drawing; they are not stored as an external project file. As a result they are loaded as the drawing is loaded. Embedded projects are typically made of reactor macros that will run in response to some action in the system, although they can also include macros initiated by the VBARUN command. There are many reactors that can be used for a variety of purposes--too many to get into at this point. You can learn about them all inside the VBAIDE.

A primary advantage of an embedded macro is that it travels with the drawing. When you send the drawing to another workstation or user, you do not have to be concerned that the macro is also sent along and properly utilized. Thus macros that are needed for the analysis or interpretation of graphics can be stored with the geometry that is involved.

To save a project as an embedded project, use the VBAMAN command and select a project from the list presented. Then press the Embed button. If the Embed button is not active, you do not have a project selected. When the drawing is saved, the project will be saved with it, and the next time the drawing is opened in AutoCAD, the project will be loaded into memory.

Of course a primary disadvantage of using embedded macros is that the projects are not saved in a manner that can be shared by multiple drawings. That is, you save the project with the drawing and the only way to retrieve the code for the project is to load the drawing. Embedded macros work best when saved in a template or prototype drawing that is the basis for a set of new drawings. In that situation the embedded macro will be saved in any new drawings created based on the template.

Applications where the embedded macro concept can be exploited include management tools such as tracking drawing time, plotter usage, and controlling modifications to entity and table objects. Through the use of specially named functions, an embedded project can be immediately aware of anything that happens inside AutoCAD after it is loaded. These specially named functions are called reactors since they react to events in the CAD system. Thus when used properly an embedded project can be a powerful tool.

DVB Files
The other way to store a project is as a DVB file. DVB files exist outside a drawing and can therefore be loaded into multiple drawings as needed. DVB files are loaded using VBAMAN or VBALOAD. VBALOAD is the faster way to load DVB projects, and there is a Visual LISP function counterpart that works very well that we will visit shortly. Once the DVB is loaded, the macros it contains are available to be run using the VBARUN or VBAMAN commands.

DVB projects can contain their own set of reactor functions. You can have a reactor function that is part of an embedded project and several more of the same type associated with other projects. This can get rather confusing, and you cannot count on the sequence in which the reactors will be fired; thus, I strongly recommend against such tactics unless the application absolutely requires it.

VBA Hassle and Workaround
When using VBA projects, there are two areas that can be a hassle and for which the workaround is not at all obvious at first glance. The first is the "Virus" warning that can occur when loading a DVB file or a drawing that contains an embedded macro, as shown in Figure 1.

Figure 1. The pesky pop-up Macro Warning Message.

When a project containing macros is loaded into a drawing or a drawing containing a macro is loaded into the editor, the alert shown in Figure 1 will be presented. To turn off the virus scare warning, use the VBARUN command. When VBARUN is executed a dialog box will be shown. Select the Options button to display a set of toggles where you can enable or disable the dialog display for the virus warning.

There is another way around the virus-warning dialog that just so happens to be related to that other hassle one encounters when using projects, namely what occurs when you try to tie VBALOAD and VBARUN into a menu macro. If the project is already loaded, VBALOAD results in an error and the VBARUN part of the menu macro is never executed.

The solution to both of these problems is to simply use Visual LISP. And no, I am not saying to stop programming in VBA and do everything in Visual LISP! What I am referring to are the Visual LISP counterparts to VBALOAD and VBARUN called (VL-VBALOAD) and (VL-VBARUN).

(VL-VBALOAD) has one parameter--a string with the file name of the DVB project. When successful, the function returns the string name of the project just loaded; otherwise nil is the result. But the best feature is that the dialog box warning about virus infection potential does not appear and execution does not halt at the Visual LISP level for a project already being loaded.

The (VL-VBARUN) function takes a little more time to get used to. The reason is that it will run simultaneously (or as best it can) with your Visual LISP function. Do not treat a VBA function like a subroutine unless you take extra steps for the task-to-task communications. That is, you cannot expect your Visual LISP function to stop execution while the VBA macro runs and then pick right up when the VBA macro is finished. In order to achieve this, special coding must take place to handle the task management. I normally recommend dividing up your task so that if you need to pass off control to a VBA macro, make it the last thing the Visual LISP macro does. And the same the other way around when running Visual LISP functions from inside a VBA program.

So which do I prefer? I tend to use DVB projects more often than embedded projects for the type of programming work I'm involved in. DVB projects allow me to move the project to drawings and load them as needed, thus not adding any additional overhead to a drawing. I have used embedded projects before in special cases where management of the drawing system was desired and have found this tool to work very well for that situation.

Until next time, keep on programmin'!