
Let us now continue to refactor according to good design principles.
Ok, so we’ve done some significant refactoring.
We’ve considered a lot of things. Some things still to be improved:
Here is the code thus far:
Ok, that’s certainly a bit better. Still the namining of the classes is quite poor; and we have the dependency inversion issues that we need to fix. Also is there any need to pass in the beams object direction when at the end of the day, we are converting it to a data structure which the printer can understand? Perhaps we should just pass in the printed data structure? We will address these concerns in Part 3 of our refactoring.

We will attempt to do something which is seldom done or discussed in Tekla code samples: and that is the very important issue of refactoring code.
The first thing you need is a good suite of tests. That way you will know whether something has gone wrong or not. It might be tricky doing this since we are developing within the Tekla environment, but I do suppose it’s possible.

WARNING: The code is very dirty. There’s a lot of repetition here. And I’ve gone up some cul de sacs incorrectly. But that’s ok. It’s code which works. We can worry about refactoring for another day – in fact, that will make for a very good exercise. Here is a link to where I document the refactoring process.
I’ll walk you through the code:
Here is the full code unencumbered by commentary:
Clear lines of communication is one of the keys to the success of any organisation.
Now you can easily track and record information pertaining to panels with a QR code on each panel drawing.
Here’s how it works:
In this case, we can record things like:
Once the status is recorded, or issues are raised, this is tracked and recorded by the app.
The basic point is that it is very difficult to track and record information pertaining to a panel throughout the entire organisation. Not anymore!


A nifty little tool that automatically inserts trusses into bubble deck panels depending on:
And also their:
Please remember to select all the panel lines.
You can see a video demo here:
Create Truss – Tek1 Tools for BubbleDeck from Tek1 on Vimeo.

In the last part we left off having obtained all the bolt distance and placing them in a domain object. In this instalment we will try to export all that data into an Excel Spreadsheet. Please note that the following code is untested – unfortunately there was a lightening storm in Melbourne which short circuited my flux capacitor which means I cannot connect to the TeklaServer – so rather than wait, I thought to get this code out to you.
There are many libraries out there: XLS compatible and not:
The consensus is that the worst of the above is still better than using Microsoft’s office interop dll. If you use that approach, you will need to ensure that MS Office is installed in your deployment machine, and secondly, be sure to dispose of all relevant objects. If you forget, then you’ll be leaking memory. This is a very important point.
* A significant change has been made – we are now filtering the SinglePartDrawings based on: (i) whether they are beams or not and (ii) whether they have the relevant profile – a reader wrote an email asking for this version of the code. I have left the previous version out there as well.
* I’m not an expert with ClosedXML – I just wanted to get the code out there. So it’s a very hackish and non-elegant solution, but I hope it serves to illustrate the point.
Have you ever fallen down a flight of stairs? I hope not! But from experience I can tell you that it’s not a very pleasant one. I slipped as I was walking down – I fell supine, hard, like a hammer on a nail, bang into the corner of the steps. The pain was absolutely numbing – I could walk for about three days, nor could I even roll over in bed for about that same period. Falling down stairs is a dangerous business – and if you’re in the business of designing or fabricating stairs – especially public access stairs, then you absolutely have to get it right. Because if you don’t, then it’s only a matter of time till someone falls. Luckily I was a young man, so I recovered pretty quickly. But if I was an invalid, a fall like that could be potentially life threatening!

The steps are not uniform – they vary in height and length. This is not safe if you are traversing it. It’s easy to misjudge. That’s why when we do the shop drawings for a flight of stairs we check that it’s uniform, that you don’t have too many stairs in a flight, that there’s adequate room, that a child cannot squeeze his/her head in between the treads, etc. I have ascended and descended these steps – and were it not for the handrails, it would be very dangerous. Don’t do steps like this. Here were the measurement from the bottom riser going up:
The risers vary too much!
Our staff are trained to ensure that their stairs comply with Australian Standards. We’re definitely not the cheapest, but we’ll know if we see a bad design – and knowing that information could save you a bundle.

The problem with using a database, when you have another primary source of information, is that the database needs to be updated. Constantly. If someone forgets to update the database, then you will be relying on information that is old/erroneous and not updated. That’s a huge risk. It’s the type of thing that you want to do only if your staff are disciplined, and the gravity of failure is low, should they forget. But if the reverse is true, then you’re sure to eat humble pie, and cause a lot of needless trouble and expense for yourself and all you deal with.
There was a political war over the implementation: I was for using the original database, and the boss was for creating a new one. Accuracy vs speed. Speed won the victory. And I must oblige by constantly updating a database with panel information.
Anyways enough with the back ground. [Here’s how you do it.]( https://forums.mysql.com/read.php?174,601264,601264)
And I’ll paste it in below, just in case the link fails, as it is wont to do, inevitably – at some time in the future.