Case for Project Parameters Addendum

Daniel Stine sent me an email to offer these additional thoughts regarding my Project Parameter post the other day. Rethinking that post I should have given it the title "A Case for..." instead of "The Case for...". It's really just one example of a decent reason to take advantage of Project Parameters.

Daniel writes:

Project parameters are set as either Instance or Type. This can limit your options later. For example, we have some families that have HP as a Type Parameter, but others (for flexibility) are set to Instance.

Project Parameters trump the Instance/Type setting of the same parameter (if one exists) in the family. I have seen this a few times, where the family has a parameter set to Type, and when it is loaded into the project is becomes an Instance parameter.

We have several Project Parameters for cost estimating in our template, they are assigned to all categories. This ensures all content, no matter where it comes from, will have those parameters. We do limit the number of Project Parameters for the reason you mentioned, that irrelevant information shows up for some families.

I am not sure if you mentioned this before, but it is really great that we can hide Shared Parameters in the project environment using the “visibility” toggle in the SP file.

My reply: Thanks! I thought I've mentioned this (hiding a shared parameter) before but I don't find a post specifically about it. I guess I need to add one or point to someone else's post about it instead at least. It isn't common knowledge so using the technique can really damage a person if they are struggling to figure out why it doesn't show up in their project.

Parameter Grouping

Consistency, CONSISTENCY, consistency...

This post is the result of noticing that families that were using a specific group for some parameters were not showing up in the correct group once they were added to a project.

When you create content the names you use for parameters is one thing to worry about. The Group you assign them to is yet another. We don't get much control over how we present parameters to our users, but Groups are one thing we do get some say about. We can even change them without starting over, compared with getting the parameter name or data type wrong.

If you'd like all your content to show the same grouping you'd better be consistent. Then again even if you are you may not get your way though. I should explain myself now?

Here's a parameter called "Mounting Elevation". It's neatly tucked away in the "Construction" group.

Curious about why I'm using Mounting Elevation when you can clearly see Default Elevation just above it? I can't tag something with the Default Elevation parameter (Data Devices in this situation), it's not among the parameters available in a tag family. I'm using a shared parameter for Mounting Elevation and "connecting the dots" with a formula that is equal to Default Elevation.

I loaded it into a project and all is well. A bit later I notice this. The parameter has wandered into a new group called "Dimensions". Hmmm...

I went back to the beginning, just like Vezzini told Inigo he should. I started with a blank project template and a single family. I added a shared parameter for "Mounting Height" and assigned it to the "Construction" group. Parameter showed up as expected. I went back to the family and tried to change the group to something else. Loaded back into the project, no respect...parameter still located under "Construction". Apparently once the project captured the group, it stuck, even if I change it in the family and reload it.

Next I tried adding a second family that used the same shared parameter but assigned to a different group, no change. Still assigned to the original group. Hmmm... So how did the parameter move?? I started to think that maybe I assigned the parameter to the other group originally and later decided to use "Construction" instead. That was so hours ago, don't really remember now. Just not sure anymore.

Let's mix it up a little with Project Parameters. When you use a shared parameter in your family Revit is kind enough to make them available in schedules without doing anything extra (except for titleblock families, they are a special case). I thought I'd try adding the same parameter to the project and assign it to the group I really wanted. Aaah... the parameter moved to the group I wanted!

If I edit the Project Parameter and change it again it moves to the new group. Well that's consistent at least.

Fire Protection probably isn't the best group to use though eh? My lesson learned from this fun is to think a bit harder about the groups I want to use earlier and to be really sure I'm happy with the setup before putting it in a real project. If I don't I'll either have to live with it or just add the parameter to the project too (which isn't really a hardship even if it isn't technically necessary).

Parameters Again

I've written about these a lot over the years. It seems to me that this dialog, and specifically the highlighted portion, is all too often either misunderstood or ignored.

The message seems pretty clear, to me at least, but here's my version:

• Project Parameters can be used in schedules but not for tags
• Shared Parameters can be used in schedules AND tags

I left out the part about shared with families and projects because...well...that's what the word shared means. I left off the part about exporting to ODBC because that's just another level of complexity. If you use Shared Parameters you win, you get that too.

If the information you care about is only expected to appear in a schedule then a Project parameter will suffice, it will work, it will give you the result you are after. If there is the slightest chance that someone will then ask for the same information to be used in a tag then you need to plan for a Shared parameter. You might consider only working with Shared Parameters for this reason, it's hard to out guess others.

This post "Shared Parameter File - A Little Clarification" revisits parameters and provides a summary of links to other posts I've written over the years. I've also copied them here:

What are Parameters and Why Should I Care?
Sharing Parameters Overview (Part 1)
Walking on Thin Ice
Making a Shared Parameter File (Part 2)
Shared Parameters Part 3
Shared Parameters Part 4
Ignore Good Advice
Home for Unwanted Doors