Tag: Tekla API

  • Refactoring the Code – Printing Selected Beams to Excel – Part 3 – (Tekla Open API)

    An apposite photo for refactoring, yet it is also oxymoronic.
    Refactoring is when you change, but don’t change.

     

    Let us now continue to refactor according to good design principles.

     

  • Refactoring the Code – Printing Selected Beams to Excel – Part 1 – (Tekla Open API)

    Improve by refactoring.
    Strive to improve the code. Just like this guy is trying to improve his swing. Looks like a fine golfer by the way. probably low single figure handicap, if not scratch.

    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.

     

    1. Start with Tests.

     

    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.

     

    2. General Themes:

     

    • Change names to more appropriate titles.
    • Restructure the code to make it understandable.
    • Correct any obvious defects:

     

     

  • Write Selected Beam Members to an Excel File (Tekla Open API – Tutorial)

    Members. Looks good.
    Some nice looking steel. The picture has nothing to do with the Tekla API but it’s cool nonetheless.

    What is the task at hand? 

    1. The user selects some beams.
    2. We then want to collate the following information into various Excel spreadsheets:
      1. Name
      2. Profile
      3. Length and finally Weight
    3. We want two views: the first aggregates the beams by their name and finish, and the second merely lists all the beams selected with the information listed above (length/weight etc).

     

    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:

  • Extracting Bolt Distances of Single Part Drawings (Beams) With an Output In Excel – Part 3 (Tekla Open API)

    Some holes in a person-hole lid.

    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.

    Which library to write to Excel?

    There are many libraries out there: XLS compatible and not:

    1. OpenXML libraries
    2. ClosedXML libraries
    3. NPOI
    4. EPPlus

     

    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.

    How to use ClosedXML in your code:

    1. Firstly download closedXML using NuGet Package Manager. That should add the relevant references.
    2. Secondly add the `using ClosedXML.Excel` directives.
    3. Then add the code snippets I’ve provided for you below:

    Notes on the code:

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

  • How to Programmatically Select Objects in the Model (Tekla Open API)

    Return a selection of objects back to the user.
    We can easily select objects as an input – objects which was can iterate over and apply a series of operations or checks out. But how do we return a selection of objects back to the user?

    Background: What are we trying to do?

    We have programmatically identified some model objects that we want to select in the model – to attract attention to the user and to allow her to easily identify all such objects. In this particular case we will be creating some beams. And then, we will select those beams in the model. Here is a code snippet to get you started:

     

  • How to programmatically insert Reference Models into Tekla (Tekla Open API)

    Wouldn’t it be handy if we could programmatically insert reference models into Tekla? Well you can now do so quite easily.

    Here is the code which does the hard work. (You will of course add the appropriate references and directives):

    And if you want to see a video demonstration, here it is:

    Inserting XRefs into Tekla as Reference Models from Tek1 on Vimeo.

  • How to Set Up a Tekla API Project (Tekla API Application)

    Work faster with the Tekla API

    The object of a Tekla Application is to ensure that things go smoothly on the construction site. You can see the organised chaos that is here. Avoid the real chaos. Plan ahead. 

    For the newbie this post shows how to set up a Tekla Project.

    Let us assume that you are creating a WPF desktop Application. You could also just as easily create a console application – I often do this if I simply want a quick and dirty way to test code.

    1. Go to Visual Studio.
    2. Create a new WPF project.

    Follow this gif:

    Setting up a Tekla Project
    How to Set up a Tekla WPF Application
    1. Next you need to add references to Tekla DLLs. They are contained at this location on my PC. C:\Program Files\Tekla Structures\19.1\nt\bin\plugins\ .They may be in a different version on yours. You can also download these dlls using Nuget in your Visual Studio.
    2. If you are using 19.1i version – then you can download Trimble’s nuget package named thus: 2019.1.50434

    Follow this Gif:

    Adding Tekla References

    Shows how to add references to a Tekla API WPF Project.

    1. The fourth and final step is to add directives and to then get coding.

    Some common directives and aliases that I use:

    I hope this post helps you!

  • Showing an Assembly in the Model via a Tekla Drawing (Part II) Tekla Open API + Code snippets

    We are revisiting a post I made earlier.

    Here’s the problem. You are viewing a Tekla drawing. But you have no idea what you are looking at, or where it is. This macro will take you to that very assembly in the model. It’s actually quite handy. And here is the previous post where I made allusion to the facility (you’ll find a video demonstrating its use):

    http://www.tek1.com.au/tekla-plug-in-2-viewing-an-assembly-in-the-model-from-an-assembly-drawing/

    This post marks the release of the code which does the job! Enjoy!

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

    #Tekla API #Autocad API #DOT NET 

    (more…)