How to tell if a built in parameter is bound to Instance or Type

[SuperRey]

I tried to use the same method as with the shared parameters, but it seems that the document ParameterBindings member doesn't contain this information.

Last thing I would like to do is to iterate on the current element, and then on the elements type with a try/catch block to see where is the parameter... :S

Any ideas?

[jeremytammik]

Dear SuperRey,

I searched for an answer for you by googling for "revit api parameter instance type":

http://lmgtfy.com/?q=revit+api+parameter+instance+type

One of the first hits I encountered is from The Building Coder:

http://thebuildingcoder.typepad.com/blog/2013/11/determining-whether-parameter-is-type-or-instance-b...

Please take a look at that and let us know whether it helps resolve the issue for you.

Thank you!

Cheers,

Jeremy

[SuperRey]

Thanks for the reply. English is not my native language, I think my explanation is a bit confusing.

I read the article prior to post in the forums. As I understand the ParameterBindings attribute in the documents only holds the shared parameter bindings (also I tested this, watching the contents in runtime).

The question is if I can tell if a built in parameter (not shared), i.e. BuiltInParameter.UNIFORMAT_CODE, without an element object, is bound to instances or type elements.

[Super_Rey]

I am in the same boat, did you ever find a procedure to determine binding type for built-in parameters?

[Super_Rey]

I know realize that SuperRey is my other account... So basically I am asking my past me if he ever found a solution... How ironic.

[jeremytammik]

Wow, cool! Just think, if he provides an answer!

[Super_Rey]

I am afraid not... 🙂

@jeremytammik can you perhaps throw any new light on this issue?

[jeremytammik]

Here is one brute force suggestion:

• Using a parameter filter, retrieve all elements that have a value for the required parameter.
• Check whether these elements are ElementType objects.
• If yes, the parameter is a type one, otherwise instance.

[brownbr2VHQE]

My morning laugh

[havard.leding]

Trying the same.
If you have an empty file and create a Door Schedule Revit will list all available parameters:

So the information is somewhere.
Hmm.. maybe the schedule API can get those parameters? (Without any elements)
Not sure about instance or type but maybe it can get all available parameters for a category.

[RPTHOMAS108]

You can query the schedulable fields for a created schedule of a certain category but it will likely only give you a set of parameter ids. Those will match the BIP values you already know about.

I'm not sure why it is important to know if the BIP is instance or type? If you search for a type parameter on the instance then by all accounts you will find it. It will be read-only so then you know it is on the type not the instance.

Same goes for using ElementParameterFilter.

So would need to know the usage case for this i.e. why is it important to distinguish?

[havard.leding]

Thanks for reply.
This seems like a route to go.
Looking at the API a schedule is not needed:

IList<ElementId> available = ViewSchedule.GetAvailableParameters(Doc, idCategory);

As for type or instance i guess BuiltInParameters can be either.
At least Length parameters.
Meaning like the builtin "Width" parameter on Doors.
It is default on type - but can be changed to instance if assigned to a dimension.
One family can have it on type - the other on instance.
So that might be something we cant really know until we have an element.

Didnt know type parameter returns from instance was readonly.
I always thought about those as "false positives" or something.
Didnt realize they where readonly for a reason.
(Although the above "Width" example would not be)

[RPTHOMAS108]

It wouldn't be the only reason behind a parameter being ReadOnly there are other reasons for that also.

The ReadOnly aspect is just something I've observed others state is the case although it makes sense. Generally I would know where I'm looking i.e. type or instance because of the specific BIP involved. If you need to deal with all BIPs in a generic way then that is slightly different.

The door width parameter sounds interesting as it seems to me like it is a type parameter, how do you make it an instance one specifically? I don't see why people would have an instance door width since instance parameters lead to larger numbers of variations whilst door sizes are often standardised to code requirements. There would generally be distinct BIP ids for similar type and instance parameters e.g.  'comments' and 'type comments'.

[havard.leding]

Agree the more you know about parameters before iteration start the faster it will run.
You can change to instance here:

- This will get available ParameterElements:

TableView.GetAvailableParameters(Doc, idCategory).Where(t => t.IntegerValue > 0);

It will also get you SharedParameterElements imported by a family.  (Not in the binding map)
But you still need to iterate bindings to know instance or type.

- This will get available BIP's:

TableView.GetAvailableParameters(Doc, idCategory).Where(t => t.IntegerValue < -1);

But its not that useful since its just a list of enums without context.

So overall Element.GetOrderedParameters() feels tempting as it solves BIP type/instance.
Although my parameter comboboxes will be empty until the user create elements.
Which means a BIM manager/coordinator wont be able to "set things up" in their company template.
On some dropdowns i cannot put both type and instance parameters.
Such as dropdowns for shared instance parameters used as Circuit Number.
Or shared type parameters used for classification.

Cant help but wonder if Revit knows more about BIP's than its telling us:-)

[RPTHOMAS108]

That is an interesting observation. It is peculiar that you can only switch between type and instance in that area of the UI. It is almost as if they forgot to exclude the possibility there i.e. why they don't let you do it in the family type dialogues?

I think it also demonstrates however that BIPs are not inherently instance or type to start with and how they become that depends on their associations on the elements. Likelihood is that when the type or instance is added it contains a parameter id that points to the BIP in the project. So before the element exists such a relationship isn't known.

The door width for example can be instance on one family and type on another so logically that relationship can't be defined globally by something outside of the type or instance in the project (it is a per family thing). Same could be said for system families it is about how Revit creates those items: if it adds the ids for specific parameters on the type or instance. So perhaps buried in the Revit code somewhere when it adds an object it creates that object with certain built-in parameter ids but there is no global list of such relationships (although that would be awkward to maintain).

What combobox would you put the door width parameter in if you didn't have a door (it could go in both I suppose)? You know in the end that the parameter is only going to be on either the type or the instance for each family so if you didn't consider that type/instance aspect in the UI design then what would be the consequence? You could have radio buttons to filter between shared/non-shared/built-in to reduce the list.