Kean Walmsley

  • About the Author
    Kean on Google+

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

« Using augmented reality to preview the output of Project Pinocchio | Main | Zooming to an AutoCAD entity using JavaScript »

March 26, 2013

AutoCAD 2014 for developers

AutoCAD 2014 logoToday is the official launch of 2014 family of products. AutoCAD 2014 will be available in the coming days to customers around the world. You’ll no doubt find lots of information on the interwebs regarding the product’s features, so I’m going to focus specifically on the opportunities – and requirements – the new release presents to developers.

Firstly, ADN members should refer to the (as ever) thorough information produced by the DevTech team and posted under the “Events” section of the ADN website. I expect the AutoCAD DevBlog will be making much of this available to a broader audience over the coming days/weeks. Be sure to check there often.

AutoCAD 2014 splash screenIn today’s post we’ll take a high-level look at AutoCAD 2014 for developers, and then drill into a couple of the specific areas over the coming days/weeks.

Binary compatible release

The first thing to mention is that this release is binary application compatible with AutoCAD 2013. (If you’re not sure what this means, this ancient – at least from this blog’s perspective – post should help.) Applications built for AutoCAD 2013 should just work with AutoCAD 2014. It’s also worth noting that we’re still targeting .NET Framework 4.0 with this release.

Reading between the lines, you should realise that we’re still building AutoCAD 2014 with the C++ compiler provided in Visual Studio 2010, for now (although we’re using the VS 2012 IDE with the 2010 platform toolset, in case that’s of interest to people).

Aside from application compatibility, this is also a DWG compatible release: we’re not changing the DWG file format in AutoCAD 2014.

Security features

While it’s true that existing AutoCAD 2013 applications “should just work” with AutoCAD 2014, there’s an important caveat. Building on concepts originally introduced in AutoCAD 2013 SP 1.1, AutoCAD 2014 has a much more stringent security model in place for applications. This has been introduced to combat the rise of AutoCAD-targeting malware (see my recent AUv class for some background).

We’ll go into this in more detail in a near-future post, but for now you’re likely to see this dialog when AutoCAD attempts to load a DLL from a location it doesn’t explicitly trust:

Security dialog in AutoCAD 2014

There are a number of ways to resolve this (i.e. to stop the dialog from being displayed each time AutoCAD tries to load a module from an untrusted location):

  • Use the Autoloader to load the module
    • The Autoloader folders are trusted automatically
  • Make sure the module has been digitally signed
    • Authenticode-signed executables are trusted automatically
      • This is not the same as “signing the assembly” in Visual Studio, which refers to the act of assigning a strong name to a .NET assembly
  • Add the module’s folder to the TRUSTEDPATHS (or TRUSTEDDOMAINS – see below) system variable
  • Set SECURELOAD to 0
    • Please do not do this: it really does defeat the object and leaves your system open to malware attack

JavaScript API

This, for me, is the “big ticket” item for this year’s release (from a developer perspective, of course). With it being the “lingua franca” of the web (including the mobile web and increasingly the world of cross-platform development), JavaScript is the latest programming language to be enabled to work with AutoCAD. I, for one, welcome our new web-centric overlords!

Just as with the introduction of AutoCAD’s .NET API, back in AutoCAD 2005, we weren’t “done” in just one release. The first release of the JavaScript API has been implemented with very focused goals, to allow you to:

  • Drive “in canvas” user interface activities, such as querying for user input and displaying transient graphics
  • Manipulate the current view: zoom, pan, switch Visual Style, etc.
  • Implement “out of canvas” user interface dialogs via HTML5 that connect back to AutoCAD via JavaScript

The Design Feed feature inside AutoCAD makes use of this new capability, so we’re “drinking our own champagne” (apparently another – more polite, vegetarian compatible? – way of saying “eating your own dog food”) with this API from day one.

So how do these goals translate to exposure of individual parts of AutoCAD’s core object model? Here are the pieces targeted in the V1 release:

  • Prompts
  • Transient graphics and input
  • Dragger (e.g. Jigs)
  • View manipulation
  • Commands
  • Windows
  • Drawing object operations and events
  • Bindable Object Layer (BOL)
  • Application object (miscellaneous properties)

You’ll be able to use these capabilities inside a JavaScript file or HTML page and load it inside AutoCAD using the new WEBLOAD command, Application.LoadJSScript() from .NET or acjsLoadJSScript() from ObjectARX.

That said, the way you’re most likely to implement JavaScript functionality in this release of AutoCAD is to implement an HTML5 palette that can be loaded into AutoCAD via a new overload of the PaletteSet.Add() method (one which now takes a URI parameter). You’ll need a local module (.NET or ObjectARX) to load the palette by calling this API method, but the UI itself can be hosted elsewhere and therefore be updated more easily.

If dealing with standard modal/modeless windows, you’ll use a different protocol:

  • In .NET: new overloads for the Application class methods, ShowModalWindow() and ShowModelessWindow()
  • In ObjectARX: acedShowHTMLModalWindow(), acedShowHTMLModelessWindow() and acedAddHTMLPalette()
  • In LISP: (showHTMLModalWindow) [as it only deals with modal UI]

Now as a V1 implementation, there are certainly holes in the API coverage. If you want to fill these, as a stop-gap, you can implement additional capabilities in .NET (using the JavaScriptCallback attribute to mark a method accordingly) or ObjectARX (using acjsDefun()) and then call them from JavaScript. The functions get called with a JSON fragment containing any arguments being passed. We’ll look at this mechanism in more detail in a future post.

Because it’s now possible to host such program content on the web – and not in a local folder – we’ve added the TRUSTEDDOMAINS sysvar (which is analogous to TRUSTEDPATHS for the local system) to enable specific internet domains to be marked as trusted. This URL list is not accessible via the OPTIONS dialog, but you can append to it easily via LISP [e.g. (setvar "TRUSTEDDOMAINS" (strcat (getvar "TRUSTEDDOMAINS") ";")) ] or via the Registry.

While the JavaScript API allows us to provide a more convenient protocol for certain operations – such as Acad.Editor.CurrentViewport.zoomWindow(pt1, pt2, true) to perform a Zoom Window with an animated view transition – even in addition to the ability to host content centrally it’s not enough to justify the development and introduction of a new API. The plan is to take this API technology beyond the desktop, at some point in the future. Exciting times!

GeoLocation API

The AutoCAD Map 3D team has implemented a key feature in AutoCAD 2014, allowing drawings to be geo-referenced. ObjectARX and .NET APIs (via the AcDbGeoData and GeoLocationData classes, respectively) have been provided that allow you to add geo-location information into an AutoCAD drawing.

Various properties exist that allow you to define the mapping between drawing coordinates and the real-world. Again, we’ll take a closer look at this capability in a future post.

VBA 7.1

In AutoCAD 2014 we’ve upgraded the core VBA version from 6.3 to 7.1. VBA is still being provided as a separate download, but this version now provides native support for 64-bit Windows.

We’ve been telling developers for some time to move from VBA to .NET, mainly as Microsoft’s investment in VBA was far from
clear (and the performance that was possible when using VBA 6.3 on a 64-bit OS was poor).

New life has now been breathed into the technology, which is good news, although – based on the information that was available at the time – many people have invested significant effort into porting away from it. We still see .NET as a better platform for professional, Windows-centric development, so I hope people don’t consider this effort to have been wasted.


That’s it for this quick introduction to the developer-centric capabilities in AutoCAD 2014. In the coming posts we’ll dig into the JavaScript API, defining a simple command using JavaScript before creating a simple HTML5 dialog that we’ll load into an AutoCAD palette.

blog comments powered by Disqus

10 Random Posts