The gp:drawOutline function issues ActiveX calls to display the path's polyline border in AutoCAD. The following code fragment uses ActiveX to draw the border:
;; Add polyline to the model space using ActiveX automation.
(setq pline (vla-addLightweightPolyline
*ModelSpace* ; Global Definition for Model Space
VLADataPts ; vertices of path boundary
) ;_ end of vla-addLightweightPolyline
) ;_ end of setq
(vla-put-closed pline T)
How do you make sense of this code? An essential resource is the ActiveX and VBA Reference, which describes the methods and properties accessible to ActiveX clients such as this garden path application. The “Working with ActiveX” section of the AutoLISP Developer's Guide explains how to translate the VBA™ syntax in the ActiveX and VBA Reference into ActiveX calls in AutoLISP syntax.
For the moment, though, you can gain a rudimentary understanding by scrutinizing the pattern of the two vla- calls in the preceding example. The names of all AutoLISP ActiveX functions that work on AutoCAD objects are prefixed with vla-. For example, addLightweightPolyline is the name of an ActiveX method, and vla-addLightweightPolyline is the AutoLISP function that invokes this method. The vla-put-closed call updates the closed property of the pline object, the polyline drawn by vla-addLightweightPolyline.
The Automation objects that factor into AutoLISP ActiveX calls abide by a few standard rules:
- The first argument to a vla-put, vla-get, or vla- method call is the object being modified or queried, for example, *ModelSpace* in the first function call and pline in the second call.
- The return value of a vla- method call is a VLA-object, which can be used in subsequent calls. For example, vla-addLightweightPolyline yields a return object, pline, that is altered in the next ActiveX call.
- The ActiveX object model is structured hierarchically. Objects are traversed from the application object at the topmost level down to individual drawing primitives, such as polyline and circle objects. Thus, the gp:drawOutline function is not yet complete, because the *ModelSpace* automation object must first be accessed through the root application object.