Following on from our look at the Core Console, Dynamic .NET and .NET migration for AutoCAD 2013, today we’re going to look briefly at the remaining API features in the AutoCAD 2013 release.
Model Documentation
The model documentation feature was introduced in AutoCAD 2012 – simplifying creation of 2D sections and details of 3D drawing content – and this initial API provides (primarily read-only) access to this information.
It comprises the following classes
- SectionSymbol
- SectionViewstyle
- ViewBorder
- ViewRepBlockReference
- DetailViewStyle
- DetailSymbol
The writeable aspects of the API are mostly related to the “style” objects – these can be created and edited programmatically, at least.
Non-COM Properties
Most AutoCAD developers are aware of the current need to use COM to interface with the Properties Window in AutoCAD (whether exposing static properties from custom entities, dynamic properties for standard entities or customizing the general display of properties, in some way).
With the addition of Mac support to the AutoCAD product, this was no longer a viable (or, at least, optimal) approach: as we can’t use COM on the Mac, we ultimately implemented our own property system allowing C++ developers to expose properties that would be useable on both Mac and Windows. The existing COM interfaces are not disappearing, but we’re increasingly using this non-COM architecture for property exposure.
This set of C++ classes – which is ultimately an extension of the ObjectARX class description hierarchy – allows you to describe a callable protocol (properties and methods) for objects:
- AcRxFacetProvider
- AcRxClass (Facet)
- AcRxProperty
- AcRxValueType
- AcRxValue
- AcRxAttribute
This mechanism allows C++ developers to describe properties of AutoCAD objects in a platform-independent way, but it can also be used to allow reflection over an object’s protocol – something we’re used to in the .NET world but that is not (yet?) available for standard C++.
As a C++-only capability, this is probably not something I’ll go into greater depth about, but it’s there if people want to use it.
Autoloader
While not quite fitting the description of being an API, the Autoloader is certainly a developer-oriented feature. Introduced in AutoCAD 2012, the Autoloader is really the preferred mechanism for loading your applications, moving forwards (and will be used by a lot of developers wanting to deploy different versions of their applications across AutoCAD 2012 and 2013, as we’re breaking compatibility in this release).
The Autoloader has evolved in the AutoCAD 2013 release, too. We’ve added:
- Support for F1 context-sensitive help integration
- The ability to add tool-palette support paths
- Demand-loading on command invocation for AutoLISP applications
- The option to specify a command to be called when an application is loaded
