Revit APP Blog

We know that family can be inserted into a project, sometimes we want to specify a special point when we insert the family. We can pass the point (XYZ) as the first parameter of FamilyInstanceCreationData when call Document::NewFamilyInstances.

However, how can you know whether the insertion point is the right place you input? You can call FamilyInstance::Location to get the insertion point, but in Revit, you can use following method to know what exactly the insertion point is:

Add two perpendicular module lines in a plan view, drag a family into the view and move the mouse until two model lines are highlighted, click mouse to put down the family. The cross point of the two lines is the insertion point of this family. You can know the coordinate through “Manage” tab -> “Project Location” panel -> Coordinates -> Report Shared Coordinates.

Tips: try your best to use  Parameter(BuiltInParameter) when get parameter from element.

Revit as a parametric product, we will frequently use element parameters (retrieve, modify) to achieve our own goals.

There are several ways to get Parameter from an element:
Parameter(BuiltInParameter)
Parameter(Definition)
Parameter(Guid)
Parameter(String)

All almost similar except the last one which has the least performance because it will iterate all parameters in this element until find the parameter with the specified name. However, in most cases BuiltInParameter is more meaningful for us and easy to get, so it’s better for us to use BuiltInParameter to get parameter. In addition, use this can avoid localization problem, so you don’t need to write different code for different languages.

If you do need to use string to retrieve parameter, go ahead. But keep in mind that there is another property ParametersMap. If you want to search several parameters from one element (all use string as keyword), get this map first and use the map to get parameter would be faster.

Chinese Version: 点这里。

When you develop your own application based on Revit API, there are many things that you need to know which won’t be included in the API help book or somewhere else. We call them tips. We plan to write down the tips we found or other friends found to help API developers.

Today we want to share one tip:

It’s better to write one Document::regenerate in one transaction just before its commit, and remember to re-get Elements, Views etc. after the regenerate if you put these code in one class/function.

Reason:

When document regeneration, many things may be changed including the memory allocated for the Elements/Views etc. So if you still use the Elements/View etc reference after the regenerate, things may go beyond your expectation. Just keep in mind that, the ElementId in document is stable, but the Element reference is not. Simplify the logic in one transaction will make your code easy to understand and less chance to encounter problems, sometimes one change will not be real until one regenerate. So if you found you change doesn’t work, maybe you need call regenerate.

Chinese Version: 点这里。