This is the first blog post I’m writing here at the SBS forums. I’m an independent software developer/contractor/consultant in California, former Autodesk and Gentry Systems employee working with AUD for almost two decades now [gulp]. I do not intend or want any of my blog posts to seem like an infomercial; quite the contrary, my goal here is to empower folks at utility companies using AUD and Autocad to be able to take advantage of the power of the APIs.

Note: this is going to be an evolving series of blog posts. I have some ideas for topics, mostly related to writing your own code to Autocad/AUD APIs … but I welcome any feedback for ideas about what to write about. I’m just guessing at the communal level of proficiency, comfort and interest out there, so please point me wherever you want me to go.

Time for the mailbag:

Q: What’s an “API”?
– name withheld, Encinitas, CA

I’m glad you asked. The acronym itself stands for “Application Programming Interface” and let’s allow Wikipedia to define it as “a set of routines, protocols, and tools for building software applications.” It’s actually tough to pin down APIs even that much – APIs are chunks of definitions for languages, operating systems, software products, protocols … it’s a deceivingly complex question. But 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.

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

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.

That’s huge. No software developer ever writes everything from the ground up. Every step of the way, we all work on top of what Microsoft developed as an operating system, we use what the people who wrote our programming language did, those of us reading this use public code Autodesk has written. Often times you Google an idea for a function and somebody on a web page just gives you sophisticated, relevant code that you can use. These are all APIs.

I want to repeat this concept. Once you open up the hood in Visual Studio to create a project, learn how to bring in a product’s .DLL file (e.g. from Autocad Map or AUD) and type their “namespace” at the top of your code (I’ll show you this in a couple weeks) then you can do incredible things just by typing a relevant word, a period then make choices from Visual Studio autocompleting. You might think a “real” programmer or developer is always typing 100 words a minute in a frenzy. Not true. Once I’ve looked up the proper API and “method”, from that I’m often picking the right coding word from a drop-down list. If all is going well, the mouse can be mightier than the keyboard.

So I want to see where you are with coding in Autocad and even AUD. Have you tried it? (If not, don’t be scared.) I’m not saying you’ll become a full-time coder or even need to. In some cases, clients that I’ve worked with just needed to become proficient enough to spot where I need to make a change for them, or to be able to follow the bouncing ball of the code to see what’s going on, maybe change a number or name of an Autocad layer name string.

Mainly I want to show you what’s possible in these APIs. And I also want to show you what’s particularly in AUD’s APIs. AUD is an incredible product and does so much for you automatically, once configured. But what about those times where you wonder, “Wouldn’t it be nice if in AUD if I could …” This is the one thing I think Autodesk is a little guilty of with AUD: they have given you an incredible gift with their APIs (take note, not officially supported APIs) and not really told you much about them. Hopefully that’s something we can all discuss.

By the way, I plan to focus on leveraging these through .NET project examples, and can post/discuss them in C# as well. But some of you may have tinkered with or develop custom code in VBA for Autocad. Please feel free to discuss your VBA thoughts in the comments section here, along with anything else for that matter.

Hopefully this is of interest to some or all of you. Please feel free to post your comments below. You are welcome to point me in whatever direction you’d like to go here, what you’d like to hear about AUD and Autocad APIs, coding, etc. And thanks to SBS literally for the blog in which to discuss this … in addition to the opportunity to cover this live at their September conference. Look forward to hearing from you.