We talked about all kinds of element parameter filter rules and evaluators and demonstrated their use with sample code in both C# and VB.NET in early posts. In this article, let us look at them from a broader perspective.
It is obvious that the FilterDoubleRule, FilterIntegerRule, FilterElementIdRule, SharedParameterApplicableRule, and the FilterStringRule are all necessary in the Revit API and they seem to have covered all different situations regarding parameters not only built-in but also shared/project one.
The Revit API also provides various filter evaluators for each filter rule so as to evaluate the parameter of interest based on some criteria. For example, the FilterStringRuleEvaluator class has a few derivatives,
Autodesk.Revit.DB.FilterStringRuleEvaluator
Autodesk.Revit.DB.FilterStringBeginsWith
Autodesk.Revit.DB.FilterStringContains
Autodesk.Revit.DB.FilterStringEndsWith
Autodesk.Revit.DB.FilterStringEquals
Autodesk.Revit.DB.FilterStringGreater
Autodesk.Revit.DB.FilterStringGreaterOrEqual
Autodesk.Revit.DB.FilterStringLess
Autodesk.Revit.DB.FilterStringLessOrEqual
and they can cover some common situations.
However, as we talked in another article, all these string rule evaluators cannot address a situation well enough like such, finding all rooms which have only numeric labels and are within a specific range like [10, 20]. We tried to work around the issue through deriving some new evaluators but failed due to some limitations of the current API.
There are some possible ways to resolve it for sure. One option can be to provide some other element parameter filter rules and evaluators like FilterNumericStringRule, FilterNumericStringGreater, FilterNumericStringLess, and so on; another is to fix the limitations of the API and make the mission of creating custom filter rules and evaluators really possible.
Another simpler but better way however seems for each filter rule to provide a simple argument like a delegate function instead of all those different hard coded evaluators as quite some .NET comparison methods do. In this way, people can choose to implement their evaluators in a single place at their will and a single element parameter filter rule will fulfill the entire task.
For example, in terms of the evaluator delegate function, it can have a single argument (to cover all different scenarios, it can be the Object type instead of Integer, Double, ElementId, or String) and returns a simple Boolean value. This would have made things much simpler and have made developers life much easier. In the delegate function, people do not have to restrict themselves to some rules like equal, less or greater. They can filter parameters as what they want, e.g. finding walls which length parameter is within some ranges like [10 feet, 15 feet] or (3 meter, 5 meter), or around some specific values like 20 feet or 5 meter. Another gain should be the performance as less filter rules and evaluators are needed.
By the way, besides finding those elements having a shared/project parameter associated with, evaluating them based on some value criteria may also be much needed.
ElementParameterFilter Creator of RevitAddinCoder can help create code combining various filter rules and evaluators to filter element parameters.
Recent Comments