Through the Interface

Civil 3D 2007 Service Pack 1A Released

A number of additional fixes have been included in this Service Pack, with one being of particular interest to our development partners.

If you use the Civil 3D API via COM Interop from Visual Studio 2005 (and possibly earlier versions of Visual Studio .NET), you will no longer be able to build your application once Civil 3D 2007 SP1 has been installed on your system: the installer for the first Service Pack inadvertently overwrites a few Registry keys that point to the Type Libraries for Civil 3D's COM API.

This has been addressed in Service Pack 1A, which can be downloaded from:

http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=7454845&linkID=3549304

.NET and AutoCAD

The AutoCAD Engineering first prototyped a "managed" (for "managed" read ".NET") API for AutoCAD 2004. It was pretty revolutionary stuff at the time - a mixed-mode DLL was created to expose the managed interface and marshall these calls through to "unmanaged" ObjectARX calls. There were a number of reasons .NET was - and remains - very interesting for developers...

.NET provides the ease of development previously available only (or at least primarily) to Visual Basic clients through COM. You can make use of COM or .NET components in your project, but generate simple client code using more evolved programming languages (even VB.NET is really a much more evolved language than VB6, in terms of its intrinsic capabilities).

A key benefit for Autodesk was the ability to map more complex datatypes (such as those defined in ObjectARX) to a managed API. When designing a COM API you are more limited - you can use certain basic types or beyond that define more complex interfaces based on IDispatch, but these come with a substantial design and development overhead: it is laborious to expose COM Automation interfaces for complex C++ classes. With .NET things were different... the consistency of the design of ObjectARX provided us with the capability to automate this to a great extent, generating code semi-automatically from our internal API definition database (which is the same one used to generate our API reference material for both ObjectARX and the managed API for AutoCAD).

For some initial pointers around using the .NET API to AutoCAD, check out the AutoCAD Developer Center - as mentioned previously the Labs are a great place to start. In my next few posts I'll talk about the basic structure of a simple .NET application for AutoCAD, and eventually how to harness the existing COM and unmanaged ObjectARX APIs through COM Interop and P/Invoke respectively.

Compatibility of AutoCAD applications between releases

This is a huge topic, so I'm not going to be able to do it justice in this one post.

Applications developed using AutoCAD's APIs need to be tested (and sometimes ported) to make sure they work with a new release of the AutoCAD platform. For several generations of AutoCAD we have consciously chosen to break binary application compatibility once every 3 releases (historically - but in recent memory - this happened for AutoCAD 2000, 2004 and now 2007). To make applications work on interim releases they might need minor porting work to migrate their use of Registry settings to be under the right location (for example), but we do test to minimise the pain experienced by our developers.

Also, applications implemented using different APIs typically require different efforts to port from one release to the next. Generally LISP applications are fairly portable between releases (although the names and locations of support files may change from time to time), as are COM clients (such as VBA and external VB). Applications using the managed API (C# or VB.NET clients) are a little more portable than ObjectARX (C++) applications, but as the managed API has been evolving quickly we have so far not always enforced compatibility (the exception being between AutoCAD 2005 and 2006, which was otherwise a binary application compatible release), Moving forwards I would expect to see more stability and release-to-release compatibility in our managed API to AutoCAD.

Architecturally ObjectARX applications are closest to AutoCAD's core (in terms of their implementation) so it is really for these modules that developers - whether external or internal to Autodesk - need to spend most development effort when application compatibility is broken.

So why do we break compatibility at all? Well there are a few reasons...

1. Sometimes we simply want to update API classes, to add new methods etc. While we can add non-virtual methods during an API-compatible release, adding virtual methods changes a module's v-table and breaks compatibility.
2. We also need to update our internal architecture or use of technology. An example of this is our extensive use of Unicode in AutoCAD 2007. This is a deep - and wide-reaching - change to the way AutoCAD handles strings internally, and has therefore impacted many ObjectARX function signatures.
3. Finally we also want to take advantage of the latest compiler technology to build AutoCAD. AutoCAD 2000-2002 were built with Visual Studio 6, AutoCAD 2004-2006 were built with Visual Studio .NET 2002 and AutoCAD 2007 was built with Visual Studio 2005. It's important for us to remain on a supported compiler version, in order to be able to get critical issues addressed by Microsoft, but beyond that it also provides us with new development capabilities, such as the possibility to make use of WinForms in AutoCAD and expose a managed API.

The third point has some subtleties: a pure C++ API could (in theory) be version independent, but whenever C-runtime or MFC classes are used in function signatures (or class derivations), then you do become more closely linked to the specific version of the compiler used to build the API provider (i.e. AutoCAD). So while clients of C++ APIs don't automatically need to use the same compiler version as the API provider, applications using ObjectARX do have this requirement.

So why don't we break compatibility every release? Because of the pain felt by our customers, and by developers. Non-availability of applications for a particular release has the potential to impact adoption of that release, as many customers are dependent on an independent application to perform their work. Maintaining a 3-release (which right now means a 3-year) window gives developers more time to focus on driving customer value by implementing serious enhancements to their applications when they are not focusing development effort on migration to support the basic requirements of the new platform.

It's DevTech's job to help minimise our developers' pain on both these fronts, whether when dealing with migration issues or helping explain the additional features and APIs available in a new release of one of our products.

Webcast in the making

I thought I’d mention one of the projects we’re working on in DevTech right now. We’re planning a webcast for later this year, to talk our developers through the various technologies Autodesk provides to create/access/view native DWG data and published DWF data.

Here’s the idea: we show the generation of native DWG data using AutoCAD 2007 (in this case creating a number of 3D solids). We then take show how various technologies can be used to make use of the information stored in the native DWG file. Afterwards, we’ll publish the data to DWF – showing the capacity to add custom metadata using AutoCAD’s DWF Metadata API – and then show the various technologies that can be used to access and view the published DWF data.

Here's a quick description of some of the sample applications we're building to demonstrate the various technologies.

Native DWG

1. A RealDWG application that accesses the DWG to extract the volume information of the contained 3D solids, displaying the results in a table (but not working with the geometry of the model at all).
   • Although a fairly basic sample, it demonstrates that precise analysis can be performed directly on the DWG contents without the need for a graphical display. It also shows how to make use of the .NET API to RealDWG.
2. An application with DWG TrueView embedded, to show the basic capabilities of the use of this component.
   • This sample will show to what extent it is possible to embed this control for basic DWG display (without any further analysis of the DWG contents).
3. An enhanced viewing application based on AutoCAD OEM, showing how this can look like a traditional CAD application or be embedded in another window.
   • This sample will show how it is possible to make use of AutoCAD's APIs within an enhanced viewing application. We'll be able to take the same .NET code from the RealDWG sample and show it working with an embedded viewer.

Published DWF

1. A DWF Toolkit application that access the DWF, extracting metadata about the materials used in the model and displaying a non-graphical summary of this data.
   • In a similar way to the RealDWG sample, this one looks at how it is possible to use a file access toolkit to get at the contents of DWF files. While RealDWG focuses on the precise data representing the model, the DWF toolkit allows us to get at the published graphics and metadata. In this case we'll extract material metadata we attached during the publishing process using AutoCAD's APIs.
2. Applications with the DWF Viewer embedded, showing how it can be used to create both simple and complex viewing applications.
   • This sample will show some of the cool stuff you can do with an embedded DWF Viewer - particularly around object selection events and the ability to visually isolate subsets of the graphics published out to the DWF file.

Getting started with Autodesk's APIs

Autodesk has a wide range of products that expose Application Programming Interfaces (APIs), to the point that it can be a bit overwhelming for developers new to our products. A great place to look for introductory information around developing with Autodesk software is the Developer Center on Autodesk.com:

• http://www.autodesk.com/developer

From here you will be able to navigate to individual Developer Centers for a number of our products, some of which I’ve provided direct links to below:

• http://www.autodesk.com/developautocad   (AutoCAD)
• http://www.autodesk.com/developadt   (Architectural Desktop)
• http://www.autodesk.com/developrevit   (Revit)
• http://www.autodesk.com/developmap   (Map 3D)
• http://www.autodesk.com/developmapguide   (MapGuide)
• http://www.autodesk.com/developinventor   (Inventor)
• http://www.autodesk.com/developvault   (Vault)
• http://www.autodesk.com/developdwf   (DWF Toolkit)
• http://www.autodesk.com/developbuzzsaw   (Buzzsaw)

Each of these Developer Centers contains a collection of resources that you, as an Autodesk developer, can harness to implement software based on an Autodesk platform, integrated with Autodesk product or service, or containing Autodesk component technology.

For instance, the AutoCAD Developer Center contains the AutoCAD .NET Labs, the training material my team uses when training aspiring AutoCAD .NET developers around the world. These Developer Centers also contain information on how to access the various developer-related documentation that ship with our products and SDKs.

Aside from offline learning resources, you’ll also find links to the discussion groups and to the Autodesk Developer Network, should you need to get support from other members of the Autodesk development community or directly from Autodesk.

Introduction to DevTech

I'm very pleased to be part of a great team at Autodesk: the Developer Technical Services team (DevTech), whose focus is on providing high quality services to members of the Autodesk Developer Network. Aside from providing technical support for programming-related questions, we also write technical solutions (which we call DevNotes), present at technical conferences, provide API training and mentoring (a specific type of short-term consulting), and liaise regularly with our Engineering teams.

The team is spread around the world: Mikako Harada manages our East Asia team, split between China and Japan, Murali Pappoppula manages the South Asia Pacific (SAPAC) team, based in India, Gary Wassell manages EMEA, split between the UK, France and the Czech Republic, and Stephen Preston manages our Americas team, split between the US and Canada. Everyone in the team is a programming expert focusing on multiple products and wearing many hats… We believe very strongly that providing hands-on support is a great way to develop strong technical skills that are of use in other parts of our job, so everyone in the team (managers included) is involved in answering questions from our ADN members.

The team currently covers most of the spectrum of Autodesk products exposing APIs: we have “virtual” workgroups spread around the world for our BSD, ISD, MSD, PTD and ACS products. Support for Media & Entertainment is handled by another team within the company, but we share tools (such as DevHelp Online, our web-based case-submission front-end) and processes.

You’ll hopefully get to know members of DevTech as time goes on – I’ll be using this blog to showcase their work, sharing some of the tips and techniques they use (and discover) as part of their respective jobs.

Welcome

Welcome to “Through the Interface”, a blog dedicated to programmers working with Autodesk technologies. My team, Autodesk’s Developer Technical Services (DevTech), provides technical services to members of the Autodesk Developer Network (ADN), including programming support, consulting, training and evangelism. I’ll be using this blog to share technical information about the use of our various Application Programming Interfaces (APIs) and component technologies. Members of DevTech are experts on a wide range of Autodesk’s products and APIs, so many of these posts will be contributed by members of my team.

A little about myself… I have worked with a number of Autodesk’s products and APIs over the years – my background is mainly with AutoCAD’s APIs, but I’ve also spent some serious time with RealDWG, AutoCAD OEM and ADT (as well as with WorkCenter and World, but that’s going back a bit :-). These days a good portion of my time is spent on team coordination, but I do still get involved in technical issues on a regular basis (and even answer the odd support question coming in from an ADN member).

If you have suggestions for interesting topics to cover in this blog, please feel free to contact me at kean.walmsley@autodesk.com. Neither my blog nor my email account should be considered channels for receiving support, however, and I make no guarantees that we will be able to address topics that are proposed. But please do feel free to drop me a line.