Category Archives: Autocad .Net API

This documents the work I’ve done on the Autocad API.

I will be posting code and helpful methods which you might find of use.

Thank you!

Comparing Lines – IEqualityComparer

It’s not very often that I write something on the Autocad .net API, so here’s something which you, I suppose, will need one day:

 

If you want to compare two lines, with a tolerance, in a collection then you’d need a LineComparer. The MSDN guide says that one should inherit from EqualityComparer, so unquestioningly, I did their bidding. The results are as below.

Take careful note of the Hashcode. You want lines that are similar – and are within the tolerance to return the same hashcode. If they are outside the tolerance then the chances of two different lines returning the same hashcode is minimal.

Lines are equal if their start and ends points are equal (or vice versa). They are also more or less equal if they return the same hash code. In such cases, then the equals method is run.

Turning AutoCAD curves into Revision Clouds (AutoCAD .net API)

Revision Cloud
Showing a sample revision cloud created in AutoCAD from the .net API.

It seems a common scenario that folks want certain polylines/curves etc to turn into a revision cloud.

How do we do this?

At the end of the day, the revision cloud is nothing but a polyline. You could roll your own polyline which handles the bulges and vertices so that it looks like a revision cloud – but that takes a lot of effort – the quick and dirty way of doing so involves creating the polyline programmatically and then calling an AutoCAD command on that Polyline.

There are a few ways you can call commands:

  1. Using SendStringToExecute
  2. Using Editor.Command();

I prefer the latter, because it is more flexible. SendStringToExecute operates after the command is completed – which may not suit your needs.

Here is a simple implementation – It should convert the circle into a RevisionCloud circle. Of course, you can tweak it to your own needs.

Tek1 Tools – Panel Comparisons

Demo – Tool To Compare Panels and Easily Identify Differences

Here’s the situation:

Someone from the factory floor calls in:

“Hey can you move a cast in plate across panel number ABC123”

“Sure – let me just check there are no —”

“GIVE ME THE DRAWINGS NOW!”

The problem with handing over the drawings without checking the layout is that you might make a big mistake! Or you might forget to ensure the two drawings link up and are the same.

You need a tool to easily check the panels, identify differences and to alert the detailer. This will also allow you to easily split up work. – you can assign that work to a junior detailer, so he/she gains experience, while it frees up time for you to focus on other things.

And if you do find a difference, it’s a big ordeal brining the layout up to speed. With this program, it automatically imports the pertinent block/polyline etc. without you lifting a finger.

The advantages are many. The simplicity is sublime. Enough talk.

Here’s the demo of the tool. I hope you enjoy it.

This tool currently works for only Bubble Deck. But I am going to make it work for all clients across a variety of edge cases and am going to speed up the algorithm considerably. I will post the new tool when it is completed.

Panel Comparison – Tek1 Tools from Tek1 on Vimeo.

AutoCAD-Tekla Interoperability

Tekla – AutoCAD Interoperability Tool

Tekla licenses are pricey. About $30k + maintenance per license. What if I told you that you needed 30-50% less licenses than you currently hold. That’s a huge cost saving, isn’t it?

If you only need 5 licenses (as opposed to 10), then you’ve saved $150k instantly, plus maintenance.

AutoCAD licenses are significantly cheaper.

But if only the work you did in AutoCAD could be transferred into Tekla? That would save you some licenses. That’s just what I’ve done here in my latest project. Now a significant portion of any modelling job can be done in AutoCAD and simply imported into Tekla.

You can check it out here:

Tekla – Autocad Interop. from Tek1 on Vimeo.

Human Resources Problem

Interoperability will also help improve the quality of your work: it’s tough finding people who are highly skilled in Tekla. What if I told you that you could use an AutoCAD draftsperson instead of someone well versed in Tekla, to do the same job? Now you have a potentially infinite pool of candidates to draw from.

Interested In more?

I’d love to be able to help. Just call or email us.

In Process vs Out of Process

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.

Stair Outline Routine – AutoCAD Plugin – Code Attached

An example of the type of stairs we draw. We do a lot of stairs. Both AS 1428 and AS 1657 compliant stairs.
An example of the type of stairs we draw. We do a lot of stairs. Both AS 1428 and AS 1657 compliant stairs.

 

We continue delving into our discussion of stairs. The boss hates it when I do things like this – releasing code to the public. But it’s too good not to share. Below is a routine you might find useful. We use it to model stairs – it’s super fast, and efficient. It allows us to try different things out and to discard what doesn’t work with ease. I’ve gone to the effort of drawing up an entire flight of stairs and then realised that I’m missing a tread. Then I’d have to redo the whole thing from the beginning. Once you have this outline done, the a good chunk of the work is finished.

One of our many, many versatile routines:

Here is a gif of the project:

A Stair AutoCAD Plugin
A plugin I wrote for AutoCAD. Written using c#.

And here is the code for the benefit of study.

I suppose I should refactor it, but I don’t think I’ll be changing it any time soon. So why worry?

Why do we set copy local to false?

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).