1. AutoCAD Ironman – New APIs
® 2010 Autodesk

2. Ironman APIs
Migration Issues New APIs Futures

3. Migration issues Binary compatible release .NET Framework 4
Same compiler
Version number R18.1 -> R18.2
.NET Framework 4
Visual Studio 2010 required to debug .NET addins
Addins built for AutoCAD 2011 are expected to work without change
AutoCAD Ironman is binary compatible with AutoCAD 2010 and That means any ObjectARX or .NET addin you build using the 2010 or 2011 SDK is expected to work fine in Ironman. Just update your installers to look for R18.2 in the registry. (And always build using the oldest common SDK if you’re targeting several AutoCAD versions within the binary cycle).
For ObjectARX applications in Ironman, you can just carry on building and debugging with VS2008 sp1.
Its slightly more complicated for .NET applications. Ironman requires.NET Framework 4. This means that while .NET apps built using VS2008 will load and run without problem, you have to upgrade to VS2010 if you want to be able to debug your code. This is because VS2008 can’t load Framework 4.
Mixed managed DLLs are a little more complicated again - they need VS2010 and VS2008. You build your application in VS2010 using platform toolset v90 i.e., compiling using the VS2008 C++ compiler, and targeting .NET Framework 3.5. Then you can build and debug your application fine.
The AutoCAD release after Ironman will be the start of a new binary compatibility cycle. Assuming VS2010 is still the latest version by then, we expect to switch to VS2010 for both ObjectARX and .NET development.

4. Migration steps
Test your AutoCAD 2010/2011 applications with Ironman Report any problems so we can fix them
Our call to action is to test your AutoCAD 2010 and 2011 compatible applications in Ironman as quickly as possible. Because it’s a binary compatible release, everything should work perfectly. That’s why we need you to test early – so you can tell us about any problems so we have a chance to fix them before Ironman ships. The closer you leave it to the release, the less chance any problems you report will be addressed.

5. Obituary
VBA
VBA will be included in Ironman as a separate download
Plan for it to be removed in AutoCAD ‘2013’
Heidi DDK
Display DDK will be discontinued as of Ironman
Hardcopy DDK will be discontinued soon (AutoCAD ‘2014’?)
Now its time to say goodbye to some old friends …
First of all, VBA. The VBA engine will be included in Ironman as a separate download – the same as it was for AutoCAD So if you’ve not yet migrated your VBA code, you have a little more time. But you should plan for it to be removed in AutoCAD I.e. Ironman is expected to be the last release to support VBA.
The Heidi DDK is also going away as a result OGS (One Graphics System) – our project to use a common graphics system in all our Autodesk products. There will be no 2012 release of the Display driver DDK, but any drivers created with the 2011 version will still work in Ironman. The Hardcopy (or plotting DDK) is expected to be removed a little later – probably in the AutoCAD 2014 timeframe. After this, plotting will be via system printer drivers.
If you rely on either of these DDKs, then please talk to me afterwards.

6. ADN API Wishlist Survey
Simplified Properties API (static and dynamic properties)
132
47%
Enhanced Visual LISP IDE 93
33%
Enhanced Dynamic .NET language support (e.g. C# scripting)
Simplified addin installation/deployment 92
Enhanced Dynamic Block API 90
32%
DCL replacement/enhancement 73
26%
Enhanced Dragger (Jig) API 69
25%
Additional Associativity APIs 56
20%
Solid History editing API 37
13%
Point Cloud API enhancements 36
Other (various) 35
12%
Enhanced materials API 10 4%
Now lets move on to new developer features in Ironman. But first, as we do every year, lets take a look at our annual API Wishlist survey. The items highlighted in yellow are coming in Ironman. The ones in orange are likely to come within the next few releases. We’ve started the infrastructure work now, but the changes required were too big to get them into Ironman.
There are also a few other items on the list we’re looking into. The LISP and DCL enhancements are strongly linked to the API work we’re doing for Sledgehammer, and are also (to a certain extent) dependent on our ongoing (long-term) research into a possible cross product, cross platform scripting engine. And the dynamic .NET language support is a feature that has become possible to research now AutoCAD is hosting.NET Framework 4 by default.
I’ll be talking specifically about the infrastructure work we’re doing to support the top item – a simplified properties API – later when I show you a couple of future technologies we’re working on.

7. New APIs Associative Array API Grip menus for custom entities
Comprehensive API for new associative array feature
Grip menus for custom entities
Add grip hover menus to your own entities
[For the following new API slides - All items are available in ObjectARX. Yellow items also available in .NET.]
Jim has already demonstrated the new associative array feature. This comes with a comprehensive API along the same lines as the associative surfaces API we showed you last year.
[DEMO – Philippe’s associative API sample]
Another cool API is for the new grip context menu feature we introduced in AutoCAD 2011 for polylines and splines and extended to additional entities in Ironman. This will probably be of most use to ObjectARX developers to add this functionality to their custom entities. In ObjectARX its implemented via protocol extensions. But its also going to be useful to .NET developers adding custom grip points to standard entities using the Overrule API. In .NET this API is implemented in conjunction with methods in the GripOverrule class.
[Extra information – You can only add one protocol extension to the same class. Adding two PEs derived from the same base class breaks the grip menu functionality. The protocol extension is registered for the entire class (e.g. all circles), but the GripOverrule can be filtered to only add relevant grips to specific instances].
[DEMO - .NET grip menus]

8. New APIs ResetTimes VisibilityOverrule
Resets the AcDbDatabase TDCREATE, TDUPDATE, TDINDWG, and TDUSRTIMER variables.
VisibilityOverrule
Overrule get/set visibility.
BlockTableRecord.SetIsFromOverlayReference
Toggle xref between attachment and overlay.
Then we have a few more, relatively small new APIs.
The ResetTimes API allows you to set all these listed DWG variables to zero, which is handy if you want to use these variables for simple document management tasks.
Then we have an addition to the overrule API – allowing you to invoke your own code when the visibility of an entity is set.
And the new BlockTableRecord.SetIsFromOverlayReference provides an API to achieve what has been a simple UI operation for years. I’m listing this function because (over the years) we’ve probably had more requests for this functionality from ADN members than for any other API. (This and a boundary API, which we gave you last year).

9. New APIs acdbConvertAcDbCurveToGelibCurve
Returns an AcGeCurve3d that is geometrically identical to the AcDbCurve
acdbConvertGelibCurveToAcDbCurve
Returns an AcDbCurve that is geometrically identical to the AcGeCurve3d
acdbAssignGelibCurveToAcDbCurve
Sets the specified AcDbCurve to be geometrically identical to the AcGeCurve3d
Then for ObjectARX only, we have some helper functions to create AcDb entities from the equivalent AcGe classes and vice versa.
There are a few more small API additions I’ve not mentioned. They’ll be listed in the ObjectARX helpfiles in due course.

10. Autoloader Simplified plugin deployment XML metadata describes plugin
Bundle format
Installation is just copying files
Supports .NET, ARX, DBX, LSP, FAS, CUI, MNU
XML metadata describes plugin
Version compatibility
OS compatibility
Demand load settings
Language support (future)
Support paths
Component dependencies
Jim already demonstrated the AutoCAD ‘appstore’. Whether or not you’re interested in posting plugins to the store, the autoloader feature we’ve added to Ironman is going to be a huge help to you when its time to deploy your plugins.
Think of the problems installing anything but the simplest plugin now. If you’re setting up any demand load settings in the registry, your installer has to be able to cope with the registry entries created by every AutoCAD application installed on your machine. That’s a separate registry section for each AutoCAD version, language, and AutoCAD vertical you support. Then there’s adding and removing your CUI flies. It gets complicated quickly.
The autoloader is a simple copy and paste installation mechanism. You put the components of your AutoCAD plugin into a folder structure, add an XML file containing some simple metadata, copy the folder to the Autodesk\ApplicationPlugins folder, and your application is automatically installed the next time AutoCAD is launched – demandload settings, partial CUIs, the lot.
Its probably easiest to demonstrate.
[DEMO]

11. Autoloader
<?xml version="1.0" encoding="utf-8" ?> <ApplicationPackage SchemaVersion="1.0" > <Components> <ComponentEntry AppName="DOTNETTEST1" ModuleName="./Contents/AutoloaderDotNetSample1.dll" > </ComponentEntry> </Components> </ApplicationPackage>
In our Beta testing for the autoloader, some people found the XML metadata format a little daunting, so I wanted to show you here the metadata you’d use for the simplest deployment type – a single .NET file – as we just used in the demo.
What we’ve not shown today are the elements you’d use to declare support paths, version dependencies and OS dependencies. We’ll be posting some more complex examples on the ADN website soon, and we also have a draft white paper describing the XML format.

12. AutoCAD for Mac R1 APIs are a subset of No Windows-isms
ObjectARX
LISP
No Windows-isms
COM
.NET
MFC
Do you have a potential customer base on the Mac?
The first release of AutoCAD for Mac shipped on October 15th. This first version of the product comes with a very significant API. Obviously, we couldn’t port the whole AutoCAD for Windows API in one go. But there’s definitely enough there for you to start creating viable plugin applications on the Mac. The question for you is if you have a potential customer base on that platform.
The significant omissions for R1 are:
There no Visual LISP (that’s the Visual LISP IDE and the VL functions) or DCL on the Mac. But LSP or FAS files that use supported functions can be simply copied to the Mac and they’ll run.
There are obviously no Microsoft Specific technologies like COM, .NET and MFC on the Mac, so no AutoCAD for Mac .NET, VBA or ActiveX API.
But, with these limitations in mind, porting an ObjectARX application is pretty straightforward. I don’t have a Mac with me today, so here’s a short recording showing just how easy it is to migrate or write a simple piece of ObjectARX code.

13. AutoCAD for Mac Migrating LISP applications
Copy the LISP files you want to migrate to Mac
Also copy the other LISP files (*.lsp, *.fas) they depend on to Mac
APPLOAD them into AutoCAD and run the command they implement

14. AutoCAD for Mac Migrating ARX applications
Install the ObjectARX SDK for Mac available from the ADN site
Create a new ARX/DBX project in Xcode
Copy over the *.h/*.cpp files of your project that you want to migrate to the Xcode project on Mac
Compile and try to fix any errors/warnings you get
Add AutoCAD.app as an executable to the Xcode project
Start the debugger in Xcode (that will start AutoCAD)
APPLOAD your project (*.bundle) and run your command

15. Thank you!
Questions?