Built-In Parameter Controversy

Built-In Parameter Controversy

tamas.deri
Advocate Advocate
349 Views
2 Replies
Message 1 of 3

Built-In Parameter Controversy

tamas.deri
Advocate
Advocate

Some built-in parameters causing us some headache lately. UNIFORMAT_CODE and UNIFORMAT DESCRIPTION definately, but there might be others. Element.Parameters contains them for an ElementType, but not for an Instance, which is as expected, because on the UI these are Type parameters.

First problem is Element.get_Parameter(Enum) returns a ParameterElement from the instance, instead of null, but it never has value. (from the ElementType it has)

The other problem is using these parameters as ParameterValueProvider in an ElementParameterFilter behaves in an unexpected way. In my experience a collector of instance elements gets filtered by an ElementParameterFilter that is constructed from a type parameter, which is while not self-evident, but useful. Due to the first problem this doesn't work for these parameters, because it seems that the ElementParameterFilter works on the non-existent, instance-bound Parameter, so a generic implementation of an ElementParameterFilter from any parameter behaves in an unacceptable inconsistent way.

My question: is this a bug or a feature? If this is a feature: WHY?

 

0 Likes
Accepted solutions (1)
350 Views
2 Replies
Replies (2)
Message 2 of 3

jeremy_tammik
Alumni
Alumni
Accepted solution

Yes, that is a very valid question indeed, and a very confusing feature. It took us a long time to discover and understand. It was documented by The Building Coder a couple of years ago: 

  

  

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 3 of 3

tamas.deri
Advocate
Advocate

Thanks Jeremy! This explains a lot, and makes sense after all. I was partially wrong about the ElementParameterFilter, because it passes if either the instance or the type matches the rule.

My misunderstanding came from the fact, that our tool uses the ElementParameterFilter where it has appropriate condition, but for regex checks we had a linq function that used the element.get_Parameter() method on the instance only, and that caused the inconsistency.

This leads to another problem: getting a type parameter from an instance always returns a valid Parameter element, but it is quite inconsistent wether it is readonly or not, or getting it's value with AsString() sometimes returns null, sometimes an empty string. The aspects that seem to matter are whether the parameter is builtin or shared, and also it is different for FamilyInstances and system families, so checking if the Parameter element from the instance has a value is not reliable, I can't be sure whether I have to check it's type or not.

 

 

0 Likes