Category Archives: .net (c#)

I am going to post a series of articles which attempts to explain complicated ideas in a simple fashion.

Returning Inside Using Statements (AutoCAD .net API)

WPF Databinding operations in the AutoCAD .NET API
A demonstration of using a WPF User control to display information pertaining to missing and/or extra items within a panel, using the ComparePanels Command.


While writing the above AutoCAD plug-in, I faced a small conundrum in the below code:

  • The question for you is: will the transaction be disposed of, and committed given I have returned the bool before it reaches the end of the using statement?

Will it be disposed?

The short answer is yes. The transaction object implements IDisposable. So, finally you can trust that the transaction will be disposed, and that any objects that it opens will also be similarly disposed.

Will the transaction be committed?

I had a peak into the Dispose methods using Reflector. I didn’t see any automatic committing of any transactions – so I am venturing to say that no, the transaction will not be committed. In other words, we’ll have to restructure the above code to ensure that the transaction is committed before we issue the returning statement. Perhaps the AutoDesk team should abort a transaction if it is not committed before a transaction is disposed?


So the lesson is: (i) always be sure your transaction is being committed, and (ii) a using statement obviates the need to ensure that your transaction is actually being disposed of.

Finding Blocks “Colliding” with Shear Lig Points (AutoCAD)

Showing Blocks Close To Shear Lig Points

It’s a common problem apparently. There are far too many block references placed a little too close to those pesky shear lig points. It takes discipline, but when you have 5-10 people all working on the same drawing, with different practices, it’s something that’s really easy to miss, but really expensive to discover.

So I developed a tool to take care of it.

Here is the video demo:

Checks for Clashes against Shear Lig Points from Tek1 on Vimeo.

Thanks for stopping by!

Adding a Dimension to a Beam – Drawing – Tekla Open API Tutorial

This is an example of a hello world program which dimensions a beam. I found this code in the Tekla Drawing Samples folder.

You can see it in action here:

How to dimension a beam using the Tekla Open API (c#)
How to dimension a beam using the Tekla Open API (c#)


Let’s walk through it:

  1. We have to get the relevant drawing.
  2. Then we have to get the relevant part we want to dimension.
  3. Then we get the view associated with the part.
  4. We save our current transformation plane, and we set a new transformation plane to the particular view’s display coordinate system.
  5. From here, get the part’s identifier and we select the ModelObject in the model itself – to get the relevant coordinates of the Beam we want to dimension.
  6. Once we’ve used the identifier to get the Beam we are after, and to get it’s relevant parts then we create the dimension.
  7. Remember to save back the original transformation plane.
  8. Note: if you insert the dimension then I obtained an exception. I don’t think you need to insert dimensions when working on drawings.
  9. Note 2: if you forget to save the transformation plane back to the original, then you will find that you dimensions will go wacky, next time you run the command. Always remember to leave things as you found them!
  10. Note 3: You have to have the beam in the same plane as your view otherwise it won’t draw the dimension.


Here is the code for your benefit:



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?

The importance of identifying the assumptions Behind Every Problem

My estimable colleague Rafik Ben made a blog post concerning a problem.

For reference, here it is:

So what’s so good about Rafi’s problem?

Well like most things in the world, the problem, is not the actual problem. When it comes to computer science, the *actual* problem lies in identifying or understanding it. And the assumptions one makes are no less important.

Let’s see this in example:

> A man and his son are driving in a car one day, when they get into a fatal accident. The man is killed instantly. The boy is knocked unconscious, but he is still alive. He is rushed to hospital, and will need immediate surgery. The doctor enters the emergency room, looks at the boy, and says…

> “I can’t operate on this boy, he is my son.”

> *How is this possible?*

It’s one of those things where you either have the answer instantly or you will never get it. It’s because your underlying assumptions and expectations were hidden and/or incorrect. The thesis of this post is this: identify the assumptions inherent behind every problem. For in doing so, you will be more likely to solve it successfully.

Assumptions area always inherent in a problem

Every problem has its own assumptions. And these assumptions will drive very different solutions. For example, in the post Rafi made:

  • what if one assumes that the input into the “Pair with sum” function was a disorered list vs ordered list?
  • What if one assumed that the input contained invalid data?
  • Each assumption would in turn require it’s own unique solution. And those solutions might be drastically different. It should be remembered that not all solutions were created equal.

 Assumptions to consider when formulating algorithms

 Some assumptions which I feel are important when considering problems:

  1. What are the domain/range of the inputs and outputs? (e.g. positive or negative, above zero or less than 400)
  2. What are the characteristics of the inputs/outputs? (i.e. divisible by 2, integers only, irrational numbers?).
  3. The data structure(s) of the inputs/outputs?
  4. Can you think of a structure that will make your algorithm more efficient.
  5. Is near enough, good enough? What are the costs of inaccuracy? Can we later fix inaccuracies?
  6. Time limitations?
  7. Computational power limitations?
  8. Human factors:
  • Remember, algorithms are created for the user. You might have to compromise on efficiency and/or accuracy in order to meet this need.  For example: I am positively sure that Google can do a  lot better in its search results: but the boffins there are acutely aware that it’s bad business if the user is left waiting for a search result for more than a few seconds. Consequently, there are some compromises on accuracy in favor of speed. These factors are essential when considering a solution to a problem.

Another human related issue: the problem must be understandable to the coder, and easily maintainable:

  1. Can you easily understand the problem by looking at it? Easily understood code makes maintenance a breeeze.
  2. What parts do you think will change?


Understand the problem and its assumptions, and you’re halfway there.

Here is a gist basically listing the above:

What does GroupBy do – Simple Explanation (Linq)

What is GroupBy meant to do – Simple Explanation

As always we will try to formulate a simple explanation of what is really going on.


Imagine you are at an airport and (as always) there is a queue and planes are delayed. See below. What you will immediately notice is that all of the passengers are grouped together promiscuously – standing around in slumps in no particular order. Every body is mixed up with each other.

But, when you get into the plane, everybody is grouped into three distinct orders:

  1. First class
  2. Business class
  3. Third class. These classes are defined today by folks’ ability to pay. Unlike the olden days. Anyways, let’s move on.

That’s basically what group by does. It takes a promiscuous group and separates them into distinct orders – in this case, three distinct groups of people: first, business and third class.

So now you can say:

  • Get me all the names of all the people in first class.
  • Get me the names of all the people in the middle class who live in Europe.

And it’s as simple as that! As for the technicalities: please refer to the MSDN documentation – hopefully reading it won’t cause too much discomfort.

Convert ObjectID[] to ObjectIDCollections!

When dealing with selection sets we can obtain the object ids of the objects contained within. The method though, returns an array.


But what if we want an ObjectIDCollection?


We can simply pass the ObjectID[] array into the ObjectIDCollection constructor.


Simple. The last thing you want to do is iterate through the array and add it to a collection individually. A simple yet handy hint which can save you a lot of effort.

Program to supersede and manage hundreds of drawings received via transmittal

What is the problem?

  • Superseding documents is a real pain – a great difficulty. Manually clicking and deleting files: it’s very time consuming and error prone. What if you miss an important drawing? It’s very, very easy when you get 20-30 new drawings every two days to sort through. In 3 months you’ll have a couple of hundred drawings which have to be reviewed. Who’s gonna pay for that?

Why is it a problem?

  • Essentially it’s because people want to transfer any risk associated with a project cocking up onto you. So they’ll send you, say, 700 drawings all at once. Multiple revisions of the same document. And they’ll get you to sort it all out.

What is the solution?

  • I wrote a program which takes care of everything. Saves you time and a lot of headaches. It’s literally amazing.

What does it do?

I’m using terms you may not be familiar with it, so first please take a moment to understand it: Definitions: (i) current project folder –  this is the folder on your computer where you keep only the latest drawings for a particular project. (ii) Downloaded drawings folder – this is the folder where you download any “new” drawings received from a transmittal.

                What does the program do?

  • Automatically updates your current project directory with the latest revisions which you have downloaded.
  • Cleans your downloaded drawings folder, and your current project folder, of any obsolete drawings.
  • Identifies which drawings are new and which ones are to be superseded.

So what’s the point of all this?

It allows our guys to focus on what they do best: getting good drawings to you. In other words, you’ll get more value for your dollar with us, because we don’t need to spend a lot of time sifting and updating drawings.


Please see below for a demo. Programming this had its challenges. I chose VBA because it allows users to see and tweak what is going on. This might have been more challenging if I used WPF to do the same project.


I hope you enjoy it!