Today 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.
In 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.
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:
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
- 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.
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:
- Transient graphics and input
- Dragger (e.g. Jigs)
- View manipulation
- Drawing object operations and events
- Bindable Object Layer (BOL)
- Application object (miscellaneous properties)
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]
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") ";through-the-interface.typepad.com")) ] or via the Registry.
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.
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.