RevitNetAddinWizard & NavisworksNetAddinWizard

Revit .NET API: Element.GetOrderedParameters() Method vs. Element.Parameters Property

Revit .NET Element has quite some methods and properties having something to do with the most important parameter stuffs.  Element.GetOrderedParameters() Method vs. Element.Parameters Property are two most important ones, as titled.

Here is the description about the Element.GetOrderedParameters() Method in the help file.

"The collection consists of only visible parameters associated to the element; it returns a different list than Element.Parameters.

The parameters are returned in the order in which they appear in the Revit UI within a given group; however, parameters of different groups may be mixed within this output.

Currently the Revit UI order is determined first by group and next by the order of the individual parameters."

It is kindly true.  However, not sure what the order of those returned parameters can help programmers?  It is not like those ordered ones in the Family Parameter Manager as we can control the order programmatically or users manually in that UI.  Can the order in the Element Properties dialog be changed either by users or by addins?

Here is the description about the Element.Parameters Property in the help file.

"The Parameters property contains a set of all the parameters that the element supports. These parameters are displayed in the Element properties dialog in the Autodesk Revit interface. These parameters can be retrieved and set via the parameter objects stored in this set."

It is kind of false.  Some of the returned parameters are not displayed in the Element Properties dialog at all.  That is what those by GetOrderedParameters() behave so actually.  Can we delete or add some 'parameter objects stored in this set'?  They can be retrieved for information access, of course!

In addition, as verified by the Revit API Lookup tool, some of Element.Parameters are duplicates and some are pretty weird!  Also wonder why one is Method but the other Property?  Was the method supposed to have some argument like order sequence (ascending or descending) at start maybe but had to be dropped out at last?! 

So, please forget about the Element.Parameters Property but focus on the Element.GetOrderedParameters() Method?

Any different experience or idea?  Please feel free to jump in.  

Revit .NET Element has quite some methods and properties having something to do with the most important parameter stuffs.  Element.GetOrderedParameters() Method vs. Element.Parameters Property are two most important ones, as titled.

Here is the description about the Element.GetOrderedParameters() Method in the help file.

Here is the description about the Element.Parameters Property in the help file.

Revit .NET API: FilterRule, ElementParameterFilter and FilteredElementCollector.WherePasses() - Cont.

Revit .NET API provides quite some classes and methods to filter elements and parameters.  FilterRule, ElementParameterFilter and FilteredElementCollector.WherePasses() are among those pretty important ones.

In the previous post, some general idea was provided about how to find elements with a particular built-in parameter no matter what value it may have for each.  This time, let's share some code.  The sample parameter is ALL_MODEL_COST, as suggested.  

Here is the helper method:

ICollection<ElementId> GetElementsWithCost()
{
    ElementId pId = new ElementId(BuiltInParameter.ALL_MODEL_COST);
    FilterRule rule = ParameterFilterRuleFactory.CreateGreaterRule(pId, -1.0, 0.01);
    ElementParameterFilter filter = new ElementParameterFilter(rule);

    FilteredElementCollector fec = new FilteredElementCollector(CachedDoc);
    fec = fec.WherePasses(filter);

    return fec.ToElementIds();
}

Here is the test code:

var ids = GetElementsWithCost();
MessageBox.Show(ids.Count.ToString());

As can be seen, the code is pretty simple actually for the Double StorageType case such as ALL_MODEL_COST here.  Last time, it's said that two opposite filter rules may be necessary,  created by ParameterFilterRuleFactory.CreateGreaterOrEqualRule and CreateLessOrEqualRule for example.  It also hinted that a LogicalOrFilter instead of LogicalAndFilter is also needed.  In fact, as demonstrated above, one GreaterRule is good enough.  It makes code simpler and more readable, and program faster and more reliable.

Please feel free to use the code or adjust it to meet your specific needs.  Enjoy! 

Revit .NET API: FilterRule, ElementParameterFilter and FilteredElementCollector.WherePasses()

Revit .NET API provides quite some classes and methods to filter elements and parameters.  FilterRule, ElementParameterFilter and FilteredElementCollector.WherePasses() are among those pretty important ones.

They can be used to filter out some elements from a document with some parameter criteria such as name and value, e.g. wall length is greater than something. 

A simple request comes out actually: is it possible to use them to find elements with a particular parameter no matter what value it may have in each element?

The answer is: yes, possible, but not that straightforward.  Some workaround has to be applied.  For example, if we want to find all elements with the Cost parameter, here we go.

Find the built-in parameter with coders in Revit .NET API Wizard or make some guess once in a while and do some experiences here and there.  Let's say it is ALL_MODEL_COST.

Create two opposite filter rules with methods inside ParameterFilterRuleFactory such as CreateGreaterOrEqualRule and CreateLessOrEqualRule. 

Create an ElementParameterFilter from the two rules.

Create an instance of FilteredElementCollector and call its WherePasses() method with the ElementParameterFilter instance passed in.

That is it!  Enjoy!

Revit .NET API: Document.TypeOfStorage Property or Document.get_TypeOfStorage() Method

Revit .NET API provides Document.TypeOfStorage Property in version 2020 and Document.get_TypeOfStorage() Method before.  They can tell what the storage type of a built-in parameter has, e.g. Integer, Double, String, ElementId or even None.

It is good.  With the property/method there, we can know a built-in parameter a little better; otherwise almost nothing more than its enum name and value.  If some more information could be provided such as parameter type, parameter group and unit type, that would be indeed helpful.   Just wonder what the built-in parameter storage type could really help any good parameter work without the other, especially the most important parameter type information.  Maybe that is too important for Revit itsef...

Anybody, who has used the property/method currently for some real purpose? Please...

Revit .NET API: ElementId vs Element???

Question is very simple.  Can any ElementId be opened as Element?

Answer is pretty difficult.  It depends.

For those visible stuffs on screen such as Walls, Doors and Windows, yes, their ElementId properties can be opened as their Element instances.  Even for many invisible stuffs such as Wall types, Door types and Window types, their ElementId properties behave well.  Though the opened object would be of ElementType instead of Element, we do not need to worry since ElementType is derived from Element anyway.

Challenge comes.  What about ElementId property of Parameter class then?

The answer is more difficult.  It really depends.  If the Parameter represents a built-in, the Document.GetElement(ElementId id) will return nothing.  The ElementId.IntegerValue indicates the BuiltInParameter enum value.  If the Parameter represents a shared, the call will return a SharedParameterElement.  If normal, maybe just ParameterElement.  Good enough!

What about Category then?

Its ElementId property will return nothing.  Its IntegerValue indicates the BuiltInCategory enum value.

There are hundreds or even thousands of different objects in terms of Revit .NET API, so please be careful.  Please do not take for granted that an ElementId always identifies some Element!

Revit .NET API: FamilyParameter.UserModifiable

It looks the Revit .NET API FamilyParameter.UserModifiable is not used commonly.  Based on our experience, it almost always returns false, but through checking here and there we did not figure why.

It seems the property always reads its default value (false) and exposes to outside.  So, please do not call it.

Revit .NET API: Purge Global Parameters

It is pretty straightforward to purge Global Parameters programmatically using the Revit .NET API.  The GlobalParameter class provides a few methods to help check whether it is used by dimensions, elements, or other Global Parameters.   The three nice methods are:

GetLabeledDimensions()
GetAffectedElements()
GetAffectedGlobalParameters()

If they all return nothing or empty, we can safely think the Global Parameter is not used and can be purged out from the model.  Or safer, we can check whether the Global Parameter has value or not.  If it does not have real value either, it is really unused then.

Global Parameters came out late.  They behave well.  That is pretty nice and natural.

Revit .NET API: SetAllowVaryBetweenGroups Method of InternalDefinition Class

Revit .NET API follows the try/catch/finally pattern.  Even for a can-not-be-too-simple method like InternalDefinition.SetAllowVaryBetweenGroups, try/catch block has to be always used; otherwise, the whole program logic may be broken due to the failure of the method call.

Another small matter is that the most important parameter related class InternalDefinition is still too simple.  It does not has a boolean method like CanAllowVaryInGroups available.  If it had, people could have used it quite ofter to check whether possible or necessary to set the property.

Finally, an extension method was worked out this way to save both hundreds of code lines and program reliability.   

public static bool AllowVaryInGroups(this InternalDefinition def, RvtDocument doc, bool canVary)
{
try
{
def.SetAllowVaryBetweenGroups(doc, canVary);
return true;
}
catch { return false; }
}

By the way, the original SetAllowVaryBetweenGroups method also returns something but not so clear or useful.   Not sure if any programmers had really used it in any way!

// Returns:
// The ids of elements that were updated to align the values between groups.

Another fact is that the method throws out exceptions in various situations even if for those very common ones such as Argument Null and Modification Outside Transaction.  The only necessary catch case is the ModificationForbiddenException actually!

Feel free to use the extension method if you like it.  Enjoy!

Revit Organizer 2020 Version Released and Revit Organizer 2019/2018/2017 New Builds Posted!

Revit Organizer 2020 has been released. It supports and works with Revit 2020. More features are added, e.g. Shared Parameter Updaters for both project and family models/files, Style Replacers for elements, current view, entire model and even component families, and various Text Gadgets. Some existing features are improved, e.g. Family Parameter Renamer now supports renaming shared parameters. Many issues have also been addressed.

New builds of Revit Organizer 2019, 2018 and 2017 have been posted. They are free to update.   They have pretty the same features as the new version, Revit Organizer 2020.

Online help has also been updated.  Please have a look for details of new features and improvements.

Shopping
Support
Query
More

Revit Organizer 2019 and Revit Organizer 2017 have been released.

Revit Organizer 2019 and Revit Organizer 2017 have been released. They are combo packages of Revit Parameter Organizer, Revit Family Organizer, and Revit Project Organizer that work for the corresponding Revit version, 2019 or 2018. A single installer will install the three addins all together for the target Revit version. Their communication between each other is much more effective and performance much better than standalone ones. Their costs are also pretty effective.

Download 2019
Download 2017

Shopping
Support
Query
More