AutoCAD Jaws - Migration and new APIs Now its time to look at AutoCAD APIs - how to migrate your applications to Jaws and also the new APIs we have for you this year. What Jim likes to call ‘the rice and the wine’. AutoCAD Jaws - Migration and new APIs

Today’s Agenda Jaws - Migration Issues A look ahead to Kastle API Wishlist Survey Jaws - New APIs Here’s what I’ll be covering in this presentation. I’ll begin the presentation with what you need to know to migrate your apps to the new Jaws release. Then we’ll take a quick look at the ‘Jaws + 1’ release (codenamed Kastle). There are some significant architectural changes coming in that release, so we want you to know about them now so you can start planning. Then a quick look at this year’s API Wishlish survey before we move on to the new APIs and developer features in Jaws. Image courtesy of Harmonix Music Systems, Inc.

Nondisclosure Agreement Today’s discussion is covered under your ADN Agreement with Autodesk. The information we will be providing is highly confidential, and is to be shared within your company on “need to know basis” and to no one outside your company. Autodesk makes no guarantees that anything presented or discussed will actually appear in the future. Remember – all the information in this presentation is covered by the confidentiality clauses in your ADN contract. It shouldn’t be shared with anyone outside your company, and if you tell anyone else in your company then you must make sure they also understand that it is confidential. And – of course – while I’m pretty confident that what I’m presenting today will appear in the AutoCAD Jaws, it is possible that some of the things I talk about may change or be removed before the product ships.

Migration issues Binary incompatible release DWG format change API compatibility break Version number R18.2 -> R19.0 ObjectARX and .NET plug-ins will require changes Demo videos available on ADN Beta Portal Let’s start with migration issues. Jaws is a binary incompatible release, which means that we’re moving to a new DWG format and there will be API changes that require you to refactor and rebuild your apps. Because we’re breaking binary compatibility, the AutoCAD major version number is changing - we’re moving from R18.2 to R19.0. Rather unusually this year, the binary compatibility break means .NET apps have to be migrated as well as ObjectARX apps. .NET programmers were pretty well shielded from the last binary break between AutoCAD 2009 and 2010. But the migration steps are quite straightforward. We’ve posted a couple of videos with the AutoCAD Jaws downloads on the ADN Beta portal to show you what you need to do. I’ll also quickly run through the main issues in the next few slides.

Big Split ARX apps ARX apps AutoCAD Windows AutoCAD for Server/Console Before we jump into the actual migration steps, I’m going to take a step back and explain the architectural change that is the reason for most of migration work. You may remember all this from the AutoCAD WS demo this morning, but I’ll quickly explain it again here. In the past – all of the AutoCAD core was contained in a monolithic acad.exe file. We’ve been working over the last few releases to separate out the AutoCAD logic from the AutoCAD user interface. The UI features go into acad.exe, and the logic goes into a DLL called AcCore.dll. Last year, we statically linked AcCore into acad.exe, so you didn’t have to worry about the change in architecture. AutoCAD Jaws is the first release to ship with AcCore as a separate (dynamically linked) DLL. That gives us the architecture we have here. The AcCore and AcDb DLLs contain all the AutoCAD and DWG ‘business logic’. We build AutoCAD on top of those two DLLs. AutoCAD for Mac was the first application to benefit from this architectural work, and we’ve now reached the stage where we’re building AutoCAD for Windows and AutoCAD for Mac on top of a common AcCore codestream. This separation of AcCore and acad.exe means that you have to link with some additional lib files if you’re an ObjectARX developer, or reference a new managed assembly if you’re an .NET developer. AutoCAD Windows AutoCAD for Server/Console AutoCAD Mac AutoCAD Core Engine CRX apps AcCore.dll DBX apps AcDbXX.dll

Migration steps – ObjectARX Visual Studio 2010 sp1 required General Properties Platform Toolset = V100 Target Extension must be same as Output Filename (e.g. .arx) Preprocessor definitions Min value for _WIN32_WINNT is now NTDDI_WINXP (NTDDI_WINXPSP3 recommended) Easiest way - #define WINVER NTDDI_WINXPSP3 Linker All *18.lib must be updated to *19.lib Add accore.lib, ac1st19.lib Optional Enable standard RTTI (C/C++->Language section) Let’s look at ObjectARX first. For completeness, this slide summarizes all the steps demonstrated in the video I mentioned earlier – so you can use it as a reference when you download the DevDays presentations from the ADN extranet. The videos are posted on the Beta website with the AutoCAD Jaws downloads. The most important steps are: - You’ll be using Visual Studio 2010 service pack 1 (and the VC10 compiler) to build your apps. All the old ‘18’ lib versions have changed to ‘19’ versions. You’ll reference two additional libs – accore.lib and ac1st19.lib – this is because of the Big Split architectural change.

Migration steps - .NET Target Framework 4 Reference AcCoreMgd.dll Some properties converted to Extension methods DocumentExtension DocumentCollectionExtension EditorExtension WindowExtension Some methods/properties renamed Interop assemblies no longer in GAC Build Test The changes for .NET are also mostly due to the Big Split work. Big Split means you must now reference an additional assembly in your .NET projects – that’s AcCoreMgd.dll -. We’ve also converted some properties to Extension methods. Extension methods are a way of extending the functionality of an existing class in .NET with new methods. Search for ‘extension methods’ on MSDN for more information. The existing classes (e.g. Document) are now in AcCoreMgd.dll, and the Extension classes are contained in AcMgd.dll. An example of the change is that the Document.StatusBar property has become the DocumentExtension.GetStatusBar() method. As well as this refactoring to use extension methods, we’ve also taken advantage of the binary compatibility break to rename some methods and properties to be more descriptive. You’ll find these changes listed in the ObjectARX readme posted with the ObjectARX SDK on the ADN Beta portal. And if you’re using the AutoCAD COM Interop assemblies to access the AutoCAD ActiveX API, you may notice that these assemblies are no longer registered as primary interop assemblies in the Global Assembly Cache. You should be referencing the interop assemblies in the ObjectARX SDK or in the AutoCAD Jaws installation folder, and Visual Studio defaults to embedding type information from those assemblies into your compiled DLLs anyway, so this shouldn’t affect your application deployment in any way. I’m just mentioning it so you don’t get any surprises. Updating your app should be pretty straightforward (it took me less than 10 minutes to migrate MgdDbg, which is a very comprehensive sample). Then you just have to build and test your app – and report any problems to us. [Additional info: Extension method example - Autodesk.AutoCAD.ApplicationServices.Document.StatusBar becomes Autodesk.AutoCAD.ApplicationServices.DocumentExtension.GetStatusBar() To use extension methods – In VB.NET – Add Import for Autodesk.AutoCAD.ApplicationServices.DocumentExtension (for example) In C# - Just ‘using Autodesk.AutoCAD.ApplicationServices;’ is required. If you’ve defined an alias (e.g. ‘using acap = Autodesk.AutoCAD.ApplicationServices;’), then you must also add the ‘using Autodesk.AutoCAD.ApplicationServices;’ . ]

Migration - LISP No migration required Finally, for completeness here are the migration steps for LISP applications.

VBA VBA will be available for AutoCAD Jaws Plan for it to be removed And VBA … I know none of you are using VBA any more, because you’ve all migrated to .NET. But the VBA IDE will be available for Jaws - delivered as a separate download, as it has been for the past two releases. However, don’t start using it again now you’ve migrated all your VBA code to .NET. We still plan for it to be removed in the near future.

Heidi DDK Display DDK is now discontinued As planned Hardcopy DDK will be discontinued soon Expect AutoCAD Kastle (‘2014’) to be the last release

A look ahead to Kastle Graphics engine modernization Fiber removal New APIs MSLIDE/VSLIDE Fiber removal acedCommand Document switching API breaking release Same DWG format New compiler (maybe) Tech preview available early 2012 One last migration topic before we move on to the new APIs section. Kastle is the release after Jaws (the ‘2014’ release, if you will). We’re telling you about this a year early, because there are some big architectural changes coming in Kastle that you need to plan for. What are these big changes? First is our graphics system modernization project. Last year we talked about this as a possible Jaws feature, but the work was so far reaching it turned into a two year project. If your apps are doing graphics intensive work, then you should test your app early for Kastle and give us feedback. Similarly, if you have custom entities, you’ll want to test graphics fidelity for your apps. Jim talked about this during his AutoCAD features presentation. The graphics system changes will even affect LISP and block library developers – if your apps use Slides in dialogs or image time menus. I’ll say more about that in a minute. Second is fiber removal. Fibers are a technology similar to threads that Microsoft no longer supports. AutoCAD uses fibers, so we’ve had an ongoing project to remove them from our architecture. We’ve been talking about this for a couple of year at DevDays, and we’ve previously provided information on how to test AutoCAD in fiberless mode using the NEXTFIBERWORLD sysvar. Kastle will be the first AutoCAD release to ship without fibers, so this is another feature you need to test early and report any issues to us to make we can address any issues. For most developers, fiber removal is a bigger migration issue than the changes to the graphics system. The main areas affected by the removal of fibers are how AutoCAD behaves when you switch documents and how it processes partial command tokens passed to it by acedCommand (or (command) in LISP). If your app makes heavy use of cross-document operations or you rely on invoking partial commands, then you need to get testing very early. Finally, because of these two major architectural changes, we’re going to break our traditional three year binary compatibility cycle. This means that Kastle will be an API breaking release even though its only one release after Jaws is breaking compatibility – the AutoCAD major version number will increase from R19.0 -> R20.0 to reflect this, and we may move to Visual Studio 2012 if Microsoft releases it in time. Most of the API changes you’ll see will be around the graphics system – AcGi and AcGs - and also acedCommand of course. If you’re an ObjectARX developer you’ll have to rebuild your apps, but .NET developers probably won’t have to unless they directly access one of the changing APIs. These changes are so big that we really need you to start testing your apps as early as possible in the release cycle so we can address any issues you find. That’s why we’re planning to provide an early Tech Preview sometime around the beginning of June that you’ll be able to use for your testing. It will also be available for customers to give us their feedback on the changes. This is where it gets a little complicated: The Tech Preview will have the new graphics system, along with the UI enhancements that go with it. We’re also trying to get the fiber removal work done by then too, so hopefully you’ll be able to start testing that in the tech preview as well – but the timeline is tight for fiber removal, so we may have to provide that to you a little later in the year.

Kastle - MSLIDE/VSLIDE The plan MSLIDE/VSLIDE supported by new graphics system Commands ‘undefined’ The backup plan DCL and Image Tile Menus Support existing SLD/SLB files Enhanced to support WMF WMFOUT instead of MSLIDE VSLIDE equivalent uses WMF [Note that this is a change for Kastle only – it doesn’t affect Jaws] A large part of the AutoCAD graphics modernization work has been to strip out our (now very old) 2D graphics system (based on HEIDI and WHIP) and replace it with the modern, high performance OGS engine that is already being used for our 3D graphics pipeline. This is a problem because the code for creating slides (the MSLIDE) command and for displaying slides over a drawing window (the VSLIDE command) was deeply embedded into the old 2D graphics engine. The removal of the 2D engine means the old MSLIDE/VSLIDE code has gone too. We ran a survey through DevNews last year and the feedback we received was that a lot of applications do still use slides – the large majority of which are using them either in DCL dialogs and image time menus. As a result of that feedback, our engineering team are working to ensure that the functionality you have available now will still be available with the new graphics system. That means that you can still create and use slides as you’ve always done. In this scenario, the only change is that these two commands will be ‘deprecated’. That means they’ll be removed from the documentation and are not ‘defined’ – so you will have to REDEFINE the command from your application before you can use it. However, the research for this is still ongoing, and there is a possibility that it will prove too difficult to completely reimplement MSLIDE and VSLIDE. If that does prove to be the case, then our backup plan is that DCL dialogs and image tile menus will continue to support SLBs and SLDs you’ve created in old AutoCAD versions, but we would also enhance them to support WMF. Then instead of creating new slides, you’ll be able to use the WMFOUT command to create WMF files and you could replace your old slides with WMF files instead. Additionally, the MSLIDE command would be replaced by WMFOUT, and any VSLIDE equivalent would paint a WMF file over the drawing display, and not slides.

ADN API Wishlist Survey Item % Simplified Property Palette support API 38 Enhanced Visual LISP IDE 33 Dynamic .NET language support (e.g. C# scripting) Enhanced Dynamic Block API 32 Model documentation - view creation & manipulation API 25 ‘Headless’ AutoCAD mode for fast scripting operations 18 Other (Various) 15 AutoCAD WS APIs View dependent entity display overrides 13 Content Explorer API AutoCAD/RealDWG for ‘cloud’ development Inter-product scripting API 9 Enhanced view change notifications 8 Point cloud API enhancements Additional AutoCAD for Mac APIs 6 That’s enough on migration. Now its on to new APIs. Before I talk about what’s new in Jaws, here is our usual summary of our annual AutoCAD API Wishlist Survey, ordered by the percentage of correspondents who asked for them – remember that everyone could vote for three items. The items in yellow are those that will be available for this release: I’ll be talking about simplified properties, dynamic .NET, model documentation, and headless AutoCAD in a moment. I won’t discuss the enhanced view change notifications, because that’s mainly just a couple of new events exposed by the graphics system library (ViewToBeUpdatedEventHandler, ViewWasUpdatedEventHandler, which only work in 3D shademodes in Jaws). AutoCAD WS and AutoCAD/RealDWG in the cloud are really the same thing – we already talked about those earlier today, so I won’t repeat it here.

ADN API Wishlist Survey Item % Simplified Property Palette support API 38 Enhanced Visual LISP IDE 33 Dynamic .NET language support (e.g. C# scripting) Enhanced Dynamic Block API 32 Model documentation - view creation & manipulation API 25 ‘Headless’ AutoCAD mode for fast scripting operations 18 Other (Various) 15 AutoCAD WS APIs View dependent entity display overrides 13 Content Explorer API AutoCAD/RealDWG for ‘cloud’ development Inter-product scripting API 9 Enhanced view change notifications 8 Point cloud API enhancements Additional AutoCAD for Mac APIs 6 The items that just turned orange are those we expect to be telling you about you next year. (Model documentation is a multi-release feature, so next year we’ll be talking about the more complete set of APIs being exposed. At the moment, many of them are read-only).

AutoCAD for Mac Release date now synchronized with Windows ObjectARX and AutoLISP APIs And one final slide before we move on to new APIs in Jaws. This is really just a reminder that AutoCAD for the Mac is still going strong. Our customer base is growing, and we’re continuing to invest resources in the Mac. Our AutoCAD core logic development now uses a common code base that is shared between AutoCAD for Windows and AutoCAD for Mac, which means we’ve now been able to synchronize the Mac release date with the Windows release date. We’re also gradually filling in the functionality gaps between the two – for example, we’ve recently added PDFUnderlay and Sheetset Manager. If you’re interested in creating or porting an app from AutoCAD for Windows to AutoCAD for Mac, then come and have a chat with me during a break.

New APIs Dynamic .NET AcCoreConsole Model Documentation Non-COM property system Autoloader enhancements

Dynamic .NET Utilizes .NET Dynamic Language Runtime (DLR) Access objects directly from an ObjectId Dynamic keyword in C# Object type in VB.NET Flattens AutoCAD .NET learning curve Easier VBA/LISP migration .NET Framework 4 has given us a great way to simplify the AutoCAD .NET API – its called dynamic .NET, and it makes the .NET API much easier for new .NET developers to learn. The basic idea is that if you have an ObjectId, then you can use that to access the methods and properties of the AutoCAD object it represents. That means no more transactions or opening and closing objects in your code – that’s all done for you by AutoCAD. This brings the .NET much closer to VBA than it was – and less like ObjectARX – that should significantly reduce the learning curve for anyone learning it. And if you’re already experienced with .NET development, it potentially gives you a fast prototyping environment, and even the capability to create and run dynamic .NET scripts from your app.

Demo - Dynamic .NET Its easiest to show you this in a real project, so let’s switch to Visual Studio and take a look at a sample the Philippe Leefsma from our European team has created.

AcCoreConsole ‘Headless AutoCAD’ Recognizes ‘CRX’ plug-ins Windows console application Run a script on drawing Fast batch processing Recognizes ‘CRX’ plug-ins ObjectARX .NET LISP Next we have AcCoreConsole. This is our implementation of a ‘headless AutoCAD’. AcCoreConsole is a DOS commandline executable shipped with AutoCAD Jaws. It hooks into the AcCore.dll to allow you to run a script on a drawing – without the overhead of starting up the AutoCAD UI. That gives you a fast, stable environment for building batch processing applications. Better still your script can load LISP macros, or run commands defined by ObjectARX or .NET apps. It even supports the AutoCAD demandload registry setting, so your ObjectARX app can be automatically loaded when your script tries to run a command they define.

Big Split ARX apps ARX apps AutoCAD Windows AutoCAD for Server/Console Before we go on to the demo, here’s another reminder of the Big Split work that makes this possible. AutoCAD for Windows and AutoCAD for Mac are now both being built onon top of a common AcCore codestream. And we’re now using AcCore for other applications. You saw it in action earlier when we showed you AutoCAD WS. AcCoreConsole does something similar but on your local computer. By the way, there are some requirements for your app to work with AcCoreConsole: Your app should only link with AcCore functionality (that means linking with AcCoreMgd and not AcMgd for .NET apps). And your app should only have a commandline UI – it mustn’t display any forms or dialogs. That’s why we call them CRX apps. A CRX app is a commandline version of an ARX app. AutoCAD Windows AutoCAD for Server/Console AutoCAD Mac AutoCAD Core Engine CRX apps AcCore.dll DBX apps AcDbXX.dll

Demo - AcCoreConsole Balaji Ramamoorthy in our DevTech India team has created a nice little sample app to demonstrate how to use some of the capabilities of AcCoreConsole in your own apps. (Of course, you can just use it directly from a .bat file if you prefer).

Model documentation First phase API Mostly read-only Editing of styles Classes SectionSymbol SectionViewstyle ViewBorder ViewRepBlockReference DetailViewStyle DetailSymbol The first phase of the model documentation feature appeared in AutoCAD 2012. Its been extended this year (as Jim showed you earlier), and it will be extended again this year. The first phase of the API released in Jaws is mostly a read-only API. Most of the editing APIs are for the ‘style’ objects. We expect the API to be completed when the feature is completed. Because the API is mostly read-only, I’m not going to demo it today – but I’ve listed the main classes here in case you want to look them up later. (Add AcDb to the names for ObjectARX). [Can programmatically create and edit styles now].

Non-COM property system Property Palette support without COM wrappers ObjectARX only Simple property types supported COM property system is still available Main classes AcRxFacetProvider AxRxClass (Facet) AcRxProperty AcRxValueType AcRxValue AcRxAttribute Next we have a new non-COM property system (codenamed Ubiquity). This API allows you to implement property palette support for custom entities or to create new properties for existing entities without having to use COM (as you’ve always had to do in the past. The API is C++ only in this release). We’ve been using this to expose properties on AutoCAD for Mac, and we’ve been slowly converting the AutoCAD for Windows code to use the same API. The old COM system isn’t going away, but this gives you the option to create proerties without having to write a COM wrapper. The concepts are a little in-depth to explain quickly, so I’m not going to try. We’ve included a sample project with the DevDays material on the ADN website, and Adam Nagy (who created the sample) will be recording a DevTV about it early in the new year.

Autoloader enhancements F1 Help integration Toolpalette support Demand loading for LISP commands Startup commands How many of you remember autoloader from last year’s presentation? <Ask for show of hands> Ok – well I’ll do a quick demo to remind you all. <Demo – Launch AutoCAD 2012. Copy Minesweeper bundle (or any other bundle) into %appdata%\Autodesk\ApplicationPlugins. Point out balloon notification Go to Plug-ins tab Run command by clicking Minesweeper button Return to slide show > So Autoloader is a new plug-in loading mechanism that makes it easy to deploy your products without having to write really complicated installer custom actions (or having to ask users to manually setup support paths – which looks really unprofessional). This year we’ve extended the functionality based on our experiences and on requests from developers posting apps to the Exchange store. Autoloader will now automatically register the helpfile you provide in your Autoloader bundle so it is displayed when the user hits F1 when hovering over your ribbonbar buttons. You can use Autoloader to automatically create your toolpalette support paths. LISP applications can now be set to only load on command invocation, with reduces the AutoCAD startup time if you have a lot of LISP apps. You can now specify a command that AutoCAD will automatically call when your app has been loaded.

App store – Call to action Submit your AutoCAD 2012 apps Update your AutoCAD 2012 apps to support AutoCAD 2013 And last but not least, a big thank you to all of you who have uploaded your apps to the Exchange store this year. Jim talked about how we’re expanding the store in the next release, and making it much more accessible to customers – so more of them can buy your apps. I have two calls to action for you today: If you’ve not yet posted an app, then now is a good time to do it so you can benefit from our increased marketing focus on the store, and so you’re ready for the revamped store release next year. If you’ve already posted an app to the store, please update it during the Jaws Beta period so its compatible with the 2013 release as soon as the products ship.

Nondisclosure Agreement Today’s discussion is covered under your ADN Agreement with Autodesk. The information we will be providing is highly confidential, and is to be shared within your company on “need to know basis” and to no one outside your company. Autodesk makes no guarantees that anything presented or discussed will actually appear in the future.

Today’s presentations… ADN Extranet http://adn.autodesk.com Under “Events”

Questions and Answers Photographs by David Wakely

Connecting the Pieces

Autodesk, AutoCAD, Alias, Autodesk Inventor, Inventor, Maya, Mudbox, and 3ds Max are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries. Academy Award and Oscar are registered trademarks of the Academy of Motion Picture Arts and Sciences. mental ray is a registered trademark of mental images GmbH licensed for use by Autodesk, Inc. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product and services offerings, and specifications and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document.   © 2011 Autodesk, Inc. All rights reserved.