Assembly Code instance/type parameter bug

[cig_ad]

Hi all,

just happened on this odd behavior - the builtin Assembly Code (and Assembly Description) can be used to return a parameter from both instances and types (try it out - see code below). If this is a feature, it's not useful. If it's a bug then fyi.

atb Peter

[RPTHOMAS108]

It has been asked before and is not a bug. I believe it is to help facilitate the ElementParameterFilters i.e. to make the type parameters available on the instance so you can search for either on each instance object. Otherwise you would have to first know if the parameter criterial was on the instance or the type. There are also other convenient aspects for it being that way.

As you've included above there is a way of certifying where the parameter is actually coming from but the property Element.Parameter doesn't make that distinction.

You may also notice that ElementType.Parameter returns instance parameters (but for what instance) that is a bit more strange in my view.

[cig_ad]

Thanks for answering, RPTHOMAS108.

If it was the case that this is to make type parameters available directly from the instance then at least you would expect it to report the same value - but, as I point out, the instance value is an empty string, while the type parameter value is what you see in Revit.

And yes - there are other parameters in common - some trivial, some meaningless, some (as you state) Element specific parameters also available from ElementTypes. Even in this list (see image below) the Assembly Code / Description seems like a bit of an outlier.

atb Peter

[RPTHOMAS108]

Have you tried using Element.get_Parameter(BuiltInParameter). The method Element.GetParameter was introduced for the ParameterTypeId, I've not been using that.

I asked why at the time they didn't just include the overload on the property Element.Parameter. I got an answer related to C# not liking indexed properties and them moving away from those (although there are many others). Such properties are fine in C++ and VB whilst C# users know they have to add 'get_' in front of them. So I don't completely understand the motivation but perhaps it is harder for them to maintain as is.

So in my previous post I was referring to the behaviour of the property Element.Parameter (accessed as Element.get_Parameter in C#) and not the new ForgeTypeId specific method Element.GetParameter. So it is good you pointed this out and we have to now establish if the behaviour is the same or different between (Element.Parameter and Element.GetParameter not to be confused with Element.get_Parameter).

For an instance I would have expected the value to be that defined on the type unless the instance itself had the parameter.  There is the case for 'door width' this BIP can be either on the type or the instance depending on how it was set in the family. So from my perspective it is important not to have to look in two places for these kind of things (not knowing which of the two places they will be).

[cig_ad]

In fact, I was using the .get_Parameter(InternalDefinition) overload when I noticed this with Assembly Code, then tested with .get_Parameter(BIP) which is the same and finally, as perhaps  .get_Parameter may not officially be supported (doesn't show up in the api help) - Element.GetParameter which was no better.

btw -the list of parameters common to both element and elementtype - shown above - makes use of the .get_Parameter(BIP) method (iterating through all BIP enums). 

something like this:

var map = Enum.GetValues(typeof(BuiltInParameter)).OfType<BuiltInParameter>().GroupBy(p => p).Select(g => g.First())
.Where(p => wall.get_Parameter(p) != null && wall.WallType.get_Parameter(p) != null)
.Select(p => new { parameter = p, label = LabelUtils.GetLabelFor(p), instance = wall.get_Parameter(p).GetRawValue(), type = wall.WallType.get_Parameter(p).GetRawValue() })
.ToList();

where .GetRawValue() is an extension that just returns an object based on the parametertype

I tried this on several categories - Assembly Code and Description are (at least in those I looked at) always there for both elements and elementtypes.

Thanks for looking at this - Peter

[RPTHOMAS108]

Yes that is odd.

The parameters are returned but their values are not, stranger still sometimes the parameters return empty string and sometime null. I'm thinking this may be something that has changed since I last checked or I'm remembering it wrong. I always historically got the values from the objects they were on but it seemed convenient to get them all from the instance. I checked a ElementParameterFilter and that still seems to work based on checking also type values of an instance.