Category: Autocad .Net API

There seems to be a lot of confusion with folks about the difference between using the AutoCAD .net API vs the COM Interop API. They both hope to do the same things, but via different ways. Given a choice, I’d always recommend using the .net API because it is much more powerful.

In process – .net API

This means that the user has to first open AutoCAD. i.e. double click on the AutoCAD icon and start up AutoCAD. once AutoCAD is open and a drawing is opened, then the user has to type in a command: “NETLOAD” and has to select the a file – the result of all your programming/coding efforts. once that file is selected the user then has to run the command “AddLine”. the command will run as you have coded it. in order to do it this way you will need the .AutoCAD net API

Out of Process – COM InterOp

In this case, you don’t necessarily have to manually open AutoCAD up. you create your own program, and you open it (much like you would open MS word etc) and your “AddLine” command would run without you, as a user, manually opening AutoCAD and netloading etc.. if you’re going down this path you need to use the COM interop API.

Using Both

If you really want to use the .net API, but did not want to manually netload, then you can use a combination of both of the above:

From the documentation:

If you need to create a stand-alone application to drive AutoCAD, it is best to create an application that uses the CreateObject and GetObject methods to create a new instance of an AutoCAD application or return one of the instances that is currently running. Once a reference to an AcadApplication is returned, you can then load your in-process .NET application into AutoCAD by using the SendCommand method that is a member of the ActiveDocumentproperty of the AcadApplication.

As an alternative to executing your .NET application in-process, could use COM interop for your application.

Hope this clear things up for you.

When you first get into .net API programming – for AutoCAD plugins, you learn this cardinal rule: make sure the three AutoCAD dlls you refer to have copy local set to false.

Why exactly is this the case? I couldn’t find a better answer than the one offered by Fenton Webb. Here it is in full:

Take a second to look at the AcMgd.dll and AcDbMgd.dll in this folder…. Do you notice that they are much smaller than the ones in the AutoCAD installation folder? There is a big reason for this which is that since the 2010 release of the ObjectARX SDK, we have “liposuctioned” the managed reference DLL’s. I say “liposuctioned” because we literally sucked out the body of the code from each function in the assembly DLL. What we did to create these DLL’s was to actually ILDASM (MSIL disassemble) the original DLL’s, strip all the body code from them and then reassembled them using ILASM (MSIL assembler). OK, now why on earth would we do that, right? Let me explain: the WPF UI designer (and indeed the WinForms designer) in Visual Studio is pretty cool in that it does a great job of showing the design of the UI on screen obviously. The problem is that the designer does like a half-hearted parse of the code behind that controls the UI in order to work out things like how it’s displayed for instance, which when we reference the external AutoCAD managed DLL’s can cause unresolved dependency errors and thus stop the VS Designer from working properly. These dependency errors are caused by the fact that the ac*mgd.dll’s depend on acad.exe which of course the VS Designer finds impossible to load in order to resolve the dependencies. By using the “liposuctioned” assemblies in your project, all of the object definitions are in place to resolve designer parsing issues. You’ll be glad to hear that it still compiles, and loads too! Just as long as you keep the Reference property “Copy Local” set to false for each DLL.

(Taken from Fenton’s WPF AutoDesk University course notes).

What is a block? What is a block reference? And what is the difference?

Let’s use an analogy to help illustrate the concept.

*Birth certificates are like your block table record, photocopies of your certificate are like block references.**

(A) Block Definitions

Imagine you have a really important document like your GREEN card/birth certificate etc. you have to keep this document locked away in your solicitor’s office. This green card is exactly like a block table record. You only have one of this document. But let’s just say you want to have many copies of your green card.

(B) Block References

Are you going to recreate a green card (and have many originals) so you can give one to the IRS, another to the department of immigration, another to the department of homeland security etc etc? No! Of course not: you are not going to recreate it; you are simply going to make photocopies of it. It makes sense because photocopies are cheap and easy and don’t cost (much) memory.
The photocopies of your green card are like block references. you can have many photocopies of your green card, and you can paste them anywhere you want: on the street, in your home etc. you can even delete them. you can delete or destroy all of them, but you will still have your original green card located safely somewhere in your house, or your lawyers office (i.e. the block table record). If you destroy the original green card then guess what – you will no longer be able to make copies of it (i.e. you won’t be able to make any block references if you don’t have a block table record which it points to.)

Summary:

So you have the original birth certificate (block definition), and you’ve made a photo copy of your birth certificate (block reference).

Where is it all located?

The block definition is located in a place called the “block table”. Just because it is in the block table, doesn’t mean it will appear in your drawing. If you want to put it in your drawing then you need to create a block reference (which points to the block definition) and then you need to put the *block reference* into your drawing.

How to add lines etc to your drawing – what is the model space?

Imagine you are drawing on a piece of paper. if you want to have a line drawn on that paper, you have to add that line to the “model space”. The paper space is basically like some special 3d-glasses you wear to view all your drawings. Think of it like a camera lens, allowing you to see the same thing in many different shades/perspectives/views.

Geometry can be added to a block definition

Think of the block definition as a basket – it’s a basket you can add many things to. You can add, for example, lines, circles, text, all sorts of shapes into this basket. And when you are ready to draw, you can place photocopies of what’s in the basket, all over your drawing, perfectly replicating it.

Getting more technical

The “model space” is itself a block table record. And so is the paper space. When you want to add something to a drawing you will have to create a block reference and “append it” to either the model space or a paper space (or other layouts – but let’s not get into that).

Offsets from a panel are used extensively in detailing.

Here’s how to do it – simple, no? See below:

DBObjectCollection _offsetPolylines = polylineInstance.GetOffsetCurves(25);
     // offsets the polyline by 25 mm
     // the object collection should really have only one item in it: a polyline offseting the original by 25mm.

Here’s the code:

And that should select any objects that you want to select. You’ll have to put it in an array though. A handy hint which can save you a bit of grief.