Language(s) to learn for customizing AutoCAD

Dennis Howell

Architecture and Engineering, All, Construction 0 Comment

I am going to state right up front, this is my personal opinion.  Subjective in all its glory.  With that said, if you want to customize AutoCAD, which language should you learn?  In a past blog post, I showed how you could draw a line several ways using Scripts, AutoLISP, VBA and then C#.NET.  If all I wanted to do was draw a line ‘programmatically’ then I would go the easiest route with AutoLISP.  AutoLISP is easy.  ‘Easy’ though can also be a bit ‘clunky,' particularly using DCLs when a GUI is needed.  The more complex the programming requirement, the more you will find that you just can’t get there from AutoLISP.  Visual Lisp may be the answer which really opened up the ObjectARX COM model.  Visual Lisp can be said to be the VBA enabled version of AutoLISP.

Wait, now I have introduced VBA!  Some would say, VBA is the next logical step beyond AutoLISP/Visual Lisp.  And again, for developing a user interface, it is so much easier.  For the longest time, I used VBA for the GUI, and tied AutoLISP/Visual Lisp underneath.  But, slowly but surely found myself working more and more with VBA because of the VBA Editor and cross-applications capabilities.  For example, tying a spreadsheet to AutoCAD is very easy.  So, once again, the idea of ‘complexity.'

But wait, there’s more.  There is a ‘gotcha’ in there.  While I do not think AutoLISP is going away.  I do see the ‘writing on the wall’ that VBA is on its way out.  For VBA to run on AutoCAD, you will need to install more software -  the VBA Enabler.  Where once VBA was available with the installation, now it is not.  That is one ‘gotcha!’ An even bigger ‘gotcha’ is Microsoft’s move to .NET and discontinuation of VBA development.

And now I have introduced .NET.  The .NET programming environment is referred to as a ‘managed API’ versus the COM environment being ‘unmanaged’.  Autodesk is doing more and more internal development using the .NET programming.  This move enables the advantages of the .NET Framework for GUI tools and data accessing.  Also, I have found that “in-session” programming versus the “single-document” processing of AutoLISP and VBA make batch jobs much easier to manage.

Often, when discussing the move to .NET with clients, the question comes out “does it run faster?"  My experience says, yes, .NET is faster, as well as more stable, and much less likely to “stall out." Though maybe not technically proper, in layman’s terms, I often will compare it to a camel.  A camel, can carry a lot of cargo, piled on top of their back.  AutoLISP and VBA compare to piling on the camel’s back.  And there is the proverbial limit to the “add on”.  While .NET is like the camel’s ability to withstand dehydration.  It is built-in to the way their internal system works, sewn into the fabric of their beings.  Another area of concern is the “longevity” of the .NET program.  Microsoft is 100% behind .NET, and by default, now Autodesk development is as well 100% behind .NET.

Now, back to the original question.  Which should you learn?  The answer is a resounding, “It depends."  What is the goal?  What is the complexity of the need for the programming to accomplish?  As far as AutoCAD is concerned, you will always need to know a little bit of AutoLISP, if only for loading customizations and issuing custom commands effectively.  For simple, “in-house” customizations, the AutoLISP/Visual Lisp is suitable.  But when you start looking at complexity, or cross-application capability (for example connecting to Excel or even Revit), then .NET is the way to go.

Want to read a little more?  Google is your friend.  Wikipedia too is great for a comparison between the COM and .NET environments, pros and cons.