About the Author

Jeremy Tammik

Jeremy is The Building Coder and The 3D Web Coder. He is a prolific author and passionate about cooperation and sharing, working with the Forge Partner Development team on Autodesk APIs and web services, providing developer support, training, conferences, presentations, and blogging on the Revit API and cloud and mobile technologies.

Jeremy joined Autodesk in 1988 as the European technology evangelist driving AutoCAD application development in Europe, the United States, Australia, and Africa. He co-founded ADGE, the AutoCAD Developer Group Europe. He left Autodesk in 1994 to work as an independent HVAC application developer and rejoined the company in 2005.

Jeremy graduated with degrees in mathematics and physics at Marburg University in Germany, worked as a teacher and translator of both computer and human languages and as a C++ programmer on early GUI and multitasking projects. He is fluent in six European languages, vegetarian, has four kids, two grandchildren, loves cooking, climbing, hiking, sports, nature, literature, music, dancing, adventure, survival, problem solving and challenges of all kinds.

Here are a totally incomplete and out-of-date CV and snapshot of what I did in 2013.

Contact, Questions and Support

Jeremy can be contacted by email and @jeremytammik, but please don't expect him to provide support.

If you have questions on Autodesk product usage, customisation or programming, please visit the appropriate Autodesk community discussion forum.

For Revit API questions, you can go straight to the dedicated Revit API discussion forum. If you prefer, you can also use the revit-api tag on Stack Overflow.

I always prefer to discuss everything I do in public and enable the entire community to contribute and share when possible.

Therefore, please avoid misusing any of the personal channels listed below for Revit API related questions:

Getting Started

Here are some suggestions on getting started with the Revit API:

First of all, before getting started, learn the Revit product from an end user point of view. Understand the optimal workflow and best practices. If you do not, the API will be hard to understand and not make much sense.

It is also useful to learn the basic of programming in general, and of the language you choose for addressing the Revit .NAT API specifically.

A good understanding of event-driven programming is very helpful, since the Revit API is entirely event driven.

Once you have that under the hood, determine an optimal end user workflow for the task that you intend to address with your add-in.

Any step that cannot be solved through the user interface can almost certainly not be automated either.

After that, it is time to start exploring the programming environment.

The Revit SDK or Software Development Kit includes API documentation and samples. You can download it from the Autodesk Revit Developer Center.

The most important piece of documentation is the Revit API help file RevitAPI.chm listing all classes, properties and methods. That information is also available online at www.revitapidocs.com.

Another very important piece of documentation is the Revit API Developers Guide included in the Revit product help.

The most effective way to get started learning and programming with the Revit API, including installation and use of the SDK, is to work through the step-by-step instructions provided by the DevTV and My First Revit Plugin video tutorials.

Next, you can dive in deeper still by working through the self-documenting ADN Revit API Training Labs. They consist of a series of hands-on lab exercises in both C# and VB.NET accompanied by detailed step-by-step training instruction documents.

If you are in a hurry and want to skip everything else, you can just check out the hello world walkthroughs in the developer guide.

The section on Add-In Integration presents detailed information on all you need to know about installing an add-in.

Here is an overview of the the rich collection of getting started material currently available:

Reproducible Test Case

The best and clearest way to describe an API problem is normally by providing a non-confidential reproducible test case including a minimal sample macro embedded in a minimal project file to run it in and detailed step-by-step instructions specifying exactly what you are trying to achieve, the behaviour you observe, the difference between the two and how to reproduce the issue to analyse it in the debugger:

  • A short exact description of what you are trying to achieve.
  • The behaviour you observe versus what you expect, and why this is a problem.
  • A complete yet minimal Revit sample model to run a test in.
  • A complete yet minimal macro embedded in the sample model or Visual Studio solution with add-in manifest that can be compiled, loaded, run and debugged with a single click to analyse its behaviour live in the sample model.
  • Detailed step-by-step instructions for reproducing the issue, e.g. which element to pick, what command to launch etc.

The purpose of this is both to enable us to reproduce and analyse the problem and to verify that it really has been resolved.

Another even more beneficial aspect for all involved is that creating a minimal reproducible case like this can help you discover for yourself what you were doing wrong, and the issue becomes moot.

P.S. Here is an additional clarification on the importance of a minimal reproducible case directly from the development team for a specific case: With the new info it does indeed look as if we need to explore this issue in more depth. However, I doubt it is on the managed side. Unfortunately, even if it does not look like it, we really need a sample to reproduce. Unless the problem occurs every time no matter what geometry is and what happens to the element the face was taken from, it is practically impossible for us to test it (I mean, in a reasonable time). We do not necessarily need your code – I can write the code myself – but we need a workflow to reproduce, and the workflow needs to be quite detailed; like – create this wall, of this type and this position and length, at this level; put this specific window there at this exact location; etc. Let me put it this way: if I receive a case from our QA team and the description does not specify each click exactly to get to the point of failure, no matter how trivial the commands are, I cannot take the case and return it to the reporter. Naturally I always try my best to deduce the actual scenario, but I can only do so much. So, please, if you can give us something very detailed and specific it will benefit both of us. Thank you.

P.P.S. If your add-in is too large or complex: I would love to dive in and try to help you debug this, but I am sorry to say I do not have the time. You will have to continue exploring it yourself. All I can suggest is to keep at it. One approach to debugging a problem like this is: (i) Simplify it down to something absolutely trivial and stupid that is guaranteed to work – dumb it down. (ii) Once that is working, add the required complications one by one until it either works completely or fails. Once you have determined the exact point of failure, you can narrow that down further and create a minimal reproducible case: With the minimal reproducible case in hand, I can either take a look myself of pass it on to the Revit development team for further analysis.

P.P.P.S. In order to simplify installation and debugging for the development team, the preferred method to submit your sample code snippet is to include it as a macro embedded in a minimal RVT document.

License

Copyright (c) 2008-2023 Jeremy Tammik

All material provided by The Building Coder is licensed under the terms of the MIT License:

Permission is hereby granted, free of charge, to any person obtaining a copy of the software published on this blog and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Disclaimer

Please note I provide no guarantee whatsoever that anything published on this blog is useful or even legal. Some of the projects discussed here make use of experimental or risky workarounds not covered by the officially supported usage recommended by Autodesk. They are by no means production-level solutions and should not be used as is for production use. Some code presented here is just a test showing some aspects of possible uses of the Revit API and other programming functionality. Nothing published here is guaranteed to work under any conditions whatsoever. Some explorations making use of undocumented aspects may not even be legal. If you make any use of anything here, you are doing so at your own risk. You are responsible for yourself and all the software you create.

Topic Groups

Here is a random collection of pointers to blog posts on specific topics that came up in recent developer queries:

5.1. Custom Exporter

5.2. 2D Booleans and Adjacent Areas

5.3. PostCommand

5.4. Dockable Panels

5.5. Material Management and Libraries

Please also note the related topic group 5.42 on Texture Bitmap and UV Coordinate Access.

5.6. Phase

5.7. Preview Control

5.8. RstLink

5.9. Retrieving Elements Using FilteredElementCollector

In addition to the discussions and samples below, a large number of additional real-world filtering examples is provided by The Building Coder samples in the module CmdCollectorPerformance.cs.

5.10. Filter for Family Symbols

5.11. Model Review

5.12. Wall Layers

Please refer to 5.17 – Wall Layers and Compound Structure.

5.13. GitHub

5.14. Moving a Cable Tray

5.15. Room Boundaries

5.16. Unit Testing

5.17. Wall Layer Compound Structure

5.18. Room Properties

5.19. Pick Point

5.20. Visual Studio Revit Add-In Wizards

The Visual Studio Revit add-in wizards provide Visual Studio templates for generating C# and VB .NET Revit add-ins. They enable the instantaneous and automatic generation, installation and debugging of a new Revit add-in skeleton with one single click.

You can always get the most up-to-date version from the Visual Studio Revit Add-In Wizard GitHub repository.

5.21. RoomEditorApp – Room Editor Revit Add-In

Please also refer to 5.35 – Autodesk Technical Summit 2014 – a generic cloud-based round-trip real-time 2D Revit BIM editor.

5.22. Advanced Revit 2014 API Features and Samples

5.23. Extensible Storage

5.24. Control Element Colour and Material

5.25. Family API, Loading and Placing Family Instances

Families can be programmatically created, loaded and placed.

The Family API to create them is active in the RFA family context.

Family loading and instance placement works in both RVT projects and RFA family definitions.

5.25.1. Family API for Creating Family Definitions

5.25.2. Family Instance Placement

5.25.3. Loading a Family

5.26. PushButtonData Usage Examples

5.27. FamilyElementVisibility

5.28. Idling and External Events for Modeless Access and Driving Revit from Outside

5.28b Thoughts and Input on Revit I/O

Officially, you cannot currently use Revit as a server to create BIM models programmatically in a fully automated manner. However, several unofficial workarounds have been devised anyway, c.f. above, and the demarcation between driving Revit from a modeless context and using it as a server is vague.

The Autodesk Forge web services are currently being expanded to include support for RVT file read-write operations as part of the Forge Design Automation API.

5.29. ExtrusionAnalyzer

5.30. 3D Booleans, Cutting and Joining Elements

Please also refer to the topic group 5.48 – Element Intersection and Collision Detection.

5.31. Dynamic Model Updater Framework DMU

5.32. Detecting and Handling Dialogues and Failures

5.33. Need to Regenerate

5.34. BipChecker, the Revit Built-in Parameter Checker

5.35. Autodesk Technical Summit 2014 – A Generic Cloud-based Round-trip Real-time 2D Revit BIM Editor

Please also refer to 5.21 – RoomEditorApp – Room Editor Revit Add-In, describing the initial base implementation for Autodesk Technical Summit 2013.

5.36. Source Code Colourizer

5.37. Creating and Setting Up a 3D View

5.38. Creating and Setting Up a Section View

5.39. Splitting an Element into Parts

5.40. The ADN Revit MEP HVAC and Electrical Sample AdnRme

5.41. Revit and Its API is Different

5.42. Texture Bitmap and UV Coordinate Access

5.43. Point Clouds

5.44. Creating a Floor

5.45. Creating Dimensioning

5.46. Autodesk View and Data API

5.47. Exporting Individual Element Geometry

5.48. Element Intersection and Collision Detection

Please also refer to the topic group 5.30 – 3D Booleans, Cutting and Joining Elements.

5.49. Edit and Continue, Debug without Restart, Live Development

5.50. DirectShape Element

5.51. Spatial Adjacency and Thermal Energy Analysis Model

Please also refer to the topic group 5.2 – 2D Booleans and Adjacent Areas.

5.52. The Revit API Util Classes are Often Overlooked

5.53. Handling Transactions and Transaction Groups

Please note that transaction handling is sometimes also related with the need to regenerate.

5.54. Structural Extensions, REX and Results Builder

5.55. DA4R – Design Automation for Revit

5.56. Element Identifiers in RVT, IFC, NW and Forge

Twitter | | Pinterest

Jeremy Tammik

About – Topics – Index – Source

Search

Subscribe to this blog's feed

Categories

Recent Posts

Archives

More...