Hello everyone.

Over the years of running HowToAutoCAD.com I have found that hundreds, if not thousands of you are very keen to get into writing your own tools for AutoCAD. However, you can create tools for AutoCAD using VB.NET in many ways, and I often see people unsure about the difference between COM automation and using a managed .NET solution.

Without this fundamental understanding you’re going to get confused at some point why something isn’t working. So that’s the point of this post – to explain the differences, and why it’s generally better to use managed code.

What is COM ?

If you’re creating a program, you can quite easily declare a variable and use it in your code. However, if you have two programs that run separately, you don’t have access to one program from the other. If you wanted to access the value of the variable created in one program from the other, you can’t – you’re stuck.

This is why Microsoft invented COM, which stands for Component Object Model. It sets out a standard for how programs can interact with each other. What this essentially means is that we can write code in one program (say Excel for example) to automate another program (say AutoCAD).

For example, we could write this VBA code in Excel:

Set ACAD = GetObject(, “AutoCAD.Application”)
ACAD.ActiveDocument.Utility.Prompt “Hello from Excel!”

This would send an instruction to AutoCAD, through the COM interface, telling AutoCAD to prompt the user with the text “Hello from Excel!”.

This is fundamentally a great idea for solving the problem of communicating between processes, and it has been a very useful way to automate programs over the years. However, COM does have its limitations.

What are the limitations of COM ?

In order to get COM working, Autodesk have to create and maintain a COM interface for AutoCAD, so that other programs can use this COM interface. This also means that Autodesk have to explicitly create a COM interface for each feature, which also means that new functionality will not automatically work with COM. A new COM interface would have to be created.

Having to write an explicit interface for every bit of functionality makes it impractical for Autodesk to support everything. And, unless Autodesk have written a COM interface for what you want to achieve, you’re stuck.

This is essentially the problem with COM, and communicating between two programs (or processes). You’re limited to communicating through mechanisms that are supported by each of the programs.

What does the NETLOAD command actually do ?

You may have used the NETLOAD command before – this command takes a DLL file, and loads it into AutoCAD. This means that the functionality that the DLL contains has actually been loaded into the AutoCAD process, which eliminates the requirement to communicate between two programs (or processes).

This means that you no longer need to use a technology like COM, because you have direct access to the internals of AutoCAD already. This gives us much more power to do what we want, and it is much easier to manipulate AutoCAD from the inside than from the outside.

This makes using a loaded DLL very much the preferred option.

But what does “managed” code mean ?

Throughout the course of writing an application the size of AutoCAD, you would need to create many internal classes and subroutines for handling the behaviour of various aspects of the application. Being a DLL inside the AutoCAD process gives us some access to these internals, which allows us to integrate far more closely with the AutoCAD application, and potentially achieve much more, in a much more efficient way.

But in order to interact with the internals of AutoCAD, as programmers we need to know what these internals are. Furthermore, we need to write our code in such a way that it uses the internals of AutoCAD correctly.

In effect, we have to manage our code, so that we are using the same application programming interfaces (APIs) that are used by the application itself.

So for example, if AutoCAD has an internal function called “DrawLine()”, then we should also use the function “DrawLine()” in our code as well (assuming of course we want to draw a line ).

How do we know what APIs there are ?

The first thing to do is create a reference in your .NET project to the AutoCAD Type Libraries. To do this, you’ll want to right click on your project in VB.NET, and select the option to add a reference. This will pop up the form below:

For access to the managed libraries in AutoCAD, you’ll want to select “acdbmgd.dll”, “acmgd.dll” and “accoremgd.dll”. This will add the relevant type libraries to your VB.NET project, and you can then use these in your code.

What next ?

Well now you hopefully understand the difference between COM and managed .NET code. The next step is to create your first .NET project using these libraries. You’ll need to create your VB.NET project as a class library, which should cause it to compile to a DLL. Also be careful to select the appropriate VB.NET framework to use when compiling your .NET project to a DLL. Ideally you will want to target the .NET framework that your version of AutoCAD uses. You can do this by right clicking on your project, and selecting properties, and then in the Compile options. Then build your project from the debug menu, and then use NETLOAD to load your DLL, and if all went to plan you have successfully created a managed VB.NET project for AutoCAD.

That’s my piece for today – I hope this article was helpful.

Will

P.S. Don’t forget to subscribe if you found this article helpful – more tips and tutorials to come

I’ve often been in a situation where a certain command or entity seems to behave differently in one drawing compared to another. Things such as how drawing units are handled are controlled on a drawing by drawing basis, by saving system variables in the drawing. With this in mind, it can be very useful to try to reverse engineer the differences between two drawings, so that you can identify what the offending system variables might be. Identifying these variables and tracking down the root cause to our problems is fundamental to attaining a good grasp of AutoCAD, so that we will know how to tackle similar problems in future.

I’ve invented a neat way of tracking down the differences between two (or more) drawings, and it’s using an express tool called SYSVDLG. You can also access this command from the Express Tools ribbon tab, in the Tools section. Once you’ve started the command you’ll be presented with this:

This screen allows you to edit the values saved in system variables. This is great functionality, but for the purposes of our comparison between drawings we are after the “Save All” option. This option exports all system variables to a SVF file.

The SVF file is simply a text file that contains the variable name followed by its value. Although it’s not a native format to Excel, we can still open it using Excel and it will be opened with the data populated in the first column of the spreadsheet. You can simply repeat this export process for any other drawings you want to compare against, and just copy and paste the columns into the same spreadsheet like so:

Now that you have the two (or more) columns side by side, you can enter a simple formula to compare the columns. As shown above, we are just using a simple IF statement in excel to check the values of the cells, and if they’re not equal to each other then display the text “!! DIFFERENT !!”, otherwise display nothing. This is a very quick way of identifying differences that may not be immediately obvious when skimming down.

I hope you find this tip as useful as I have in the past – I’ve lost count of the number of times that I’ve been caught out by an obscure system variable that I didn’t even know existed, which was for some reason changed in a drawing that I’d inherited from someone else !

If you found this tip useful please do consider subscribing below, and if you have a tip you’d like to share, let me know!

Will

As of AutoCAD 2008, we have a new command for dealing with the layering properties of objects en-masse. The SETBYLAYER Command.

As you’d expect, this is used for setting properties to ByLayer (as they mostly should be). You might say that you can do that already by just selecting everything and changing the layer in the properties window to ByLayer. But the beauty of SETBYLAYER is that it gets into all the corners of your drawing – this one will go through every block, layout and pretty much everything else, and will change it all to ByLayer. Very useful, especially on those drawings which seem to contain loads of nested blocks with obscure properties.

There is also a menu for controlling the behaviour of the command, which also corresponds to the SETBYLAYERMODE system variable.

The variable is saved at application level, so changes you make to SETBYLAYERMODE will persist between drawings. To access the menu type “S” in the command line after invoking the SETBYLAYER command.

I hope you find this as useful as I do – it’s one of my favourite commands for cleaning up drawings.

Will

P.S. Finally, as usual I’d like to encourage all non-subscribers out there to pop your email address into the box below. I’ve loads of tips and tools to share with you all, and I want to spread the word as far as possible!