Plannedscape Postings

Image

AutoCAD and APIs (Part 1)
I Define An "API" (Again)

Posted by Charlie Recksieck on 2020-10-22
Author's Note: This is from a series of blog posts I previously wrote for Spatial Business Systems at their request on their forums for the "Automated Utility Design" community - comprised mainly of people in the electric utility industry in IT, engineering and design departments. The program (which is a great automated tool for design at power companies) runs on AutoCAD. We here at Plannedscape and me personally have coded complex extra features and integrations for AUD and AutoCAD over the years, using APIs.

This is really for a niche audience of people who want to extend AutoCAD with custom code. If it isn’t for you, we’ll see you again on posts after November 10th.

In previous posts of "What’s An API?" (Part 1, Part 2, Part 3 and Part 4 I wrote a 4-part primer for non-programmers and new programmers about what an API is. Feel free to visit that if you're up for learning more about that. This new series of articles is more specifically targeted to people developing and implementing code using AutoCAD's APIs.


* * *

Last week we looked at books that I’ve been able to use directly in my career as a software developer. Here in Part 2, I’ve listed the most influential books I’ve read that have helped my with my career that aren’t directly about software. Some are lighter reading, and the first two below are incredibly dense. But I really think there’s something for everybody here.


What's an API?

(As mentioned above, if you want a non-AutoCAD discussion of APIs here is our previous series - https://www.plannedscape.net/blog-details.php?BlogPostID=18)

I’m glad you asked. The acronym itself stands for "Application Programming Interface". Let’s allow Wikipedia to define it as "a set of routines, protocols, and tools for building software applications. For our purposes picture different chunks of code somebody has written for a software product. Even though I’ve written APIs that have routines you could publically use, and if you’ve written any simple code while dabbling, you’ve likely written an API ... but let’s specifically think about Autodesk APIs.


AutoCAD DLLs

If I’m writing .NET code in Visual Studio and I use one of the basic Autocad Map APIs (acmgd.dll) in my code, then now all of a sudden I have hundreds of procedures and objects I can use. Right off the top, I can use the DocumentManager to look at any Autocad documents (drawings) on that machine. As long as I have the Autocad DLL listed in my code project’s references (acmgd.dll), refer to its namespace (actually how to do this will be covered with examples & exercises in future blog posts if you like, don’t worry too much about specific software development terms here) then I can just type the word DocumentManager.

This might seem trivial but in Visual Studio, I type "DocumentManager" (it even auto-completes the word) and create an object, put a period right after it (DocumentManager dmMyObject. -->) and all kinds of pre-made functions and object are given to me as a choice. I can type just one more word and voila:

- I can get a collection of open drawings
- I can get the active drawing being looked at
- I can open a new drawing
- Get a count of open drawings
- or about 30 more useful actions, collections and objects pop up magically


Takeaway - "API" for AutoCAD Purposes

Keep your definition of API simple. In my case here you can think of the Autodesk DLL as an API which is fine, though it’s more correct to think of what’s inside of there (their "Application" class or "DocumentManager" class/object) as an API. Basically it’s code that somebody else has sweated over and polished up that YOU CAN USE FOR YOUR PURPOSES.

Click here to read Part 2