Parameter is Missing for Some Types

From a thread at RFO, Aaron explains what's gone wrong...

Aaron wrote:

"If someone deletes a family that is also the default option for a Family Type, with that Shared Parameter: Yes, the entire parameter gets deleted. It's terrible behavior, and its been that way for years.

In case I wasnt clear: This is a known issue, and it's easily reproducible.

1. Take any Family that uses a Shared Family Type Parameter, that has a default value.
2. Find the family in the project browser, that is the Family and Type that's in the default value.
3. Delete that family from the Project Browser.
4. After you've clicked *DELETE* in the warning, go back to the original Family (the parent family with the parameter).
5. For JUST the types that had that default value set, that parameter is now gone.

And yes, the instances in your project are hella broken, now."

Change a System Parameter from Type to Instance - Not Length

It is fairly common knowledge that we can change a built-in parameter like Width from Type to Instance by going through the side door, selecting a dimension assigned to the parameter and changing it to Instance on the ribbon (see the image).

Kurt Thompson wrote to me to share how he gets around this issue when the parameter isn't something a dimension can be associated with. Specifically he was referring to a thread at the Autodesk User Forums where a member (electrical focus) was asking Autodesk to change the default parameters for Mains (instance), MCB Rating (type) and Subfeed Lugs (type). They argue that each parameter should be the opposite of the current configuration based on how the information is really dealt with (not that he needs me to, but I agree with him).

Kurt writes:

"To change a System Type parameter to Instance...(specific to the mentioned thread)

Create a Shared Parameter built exactly like the built-in parameter you need to change but make it Instance instead of Type. Starting out with a Generic Model family, add the new parameter. Now assign the family to the category Electrical Equipment, Revit will replace the shared parameter with the built-in parameter but it will retain the Instance (or Type) property setting from the shared parameter. Give it a try."

Thanks Kurt!

Recover or Acquire a Shared Parameter

I wrote THIS POST in January of 2012 but the interface has changed quite a bit since then. I happened to see a reference to the older post and realized how dated it is. I thought about replacing the screen captures to just update it then decided to echo the post with current pictures instead.

When you don't have access to the original Shared Parameter's file there are two ways to get to it, via a family or in a schedule. Either way you need to be able to touch the parameter so you can use the Export option for shared parameters. Revit will add the parameter to the current shared parameter file you are using.

In a family you need to open Family Types, select the parameter, choose the Edit Parameter button.

In a project schedule take a look at the View Properties for the schedule, Click the Edit... button next to Fields, pick the parameter, then click the Edit Parameter button (note the Export button in the next image is not active/enabled).

Click the Export button when it is enabled and Revit will pop open this confirmation. It also tells us where to look for it in the Shared Parameter file.

If the Export button (like in the previous image) is not active that happens because Revit is not associated with a shared parameter file yet or, less likely, the Shared Parameter is already in the Shared Parameter file this session of Revit is aware of. You’ll need to choose a different file or create a new file first. You can do this via the Manage Ribbon > Settings panel > Shared Parameters button, browse to find it or create one from scratch.

It is worth noting that a titleblock family does not conform to this scenario. Shared parameters that are used in titleblocks must be connected to a project too, by adding the shared parameter to the project as a project parameter and choosing the Sheets category. It might help to consider a titleblock is very much like a Tag except the element it tags is a sheet view, not a door or wall for example.

Revit 2016 - Multiline Text Parameter and Shared Parameters

As soon as we add a new parameter using this new Multiline Text parameter type to our existing Shared Parameter file it invalidates that file for use in prior versions of Revit. If we try to access our Shared Parameter file we'll be greeted with this message.

Mulling it over for a moment, it makes sense to me since the older versions of Revit are not able to interpret this new kind of parameter because it didn't exist. Rather than allow us to continue, to create a parameter that isn't supported, it takes the hard road and prevents us from using it at all. It might be possible, via another Update Release to 2015 and for the other older supported versions, to provide code to ignore any Multiline Text values it finds when it parses a Shared Parameter file.

This means we'll need to create a separate shared parameter file for managing any Multiline Text parameters we use. We can keep on using the original Shared Parameter file(s) we already have. Just don't add any new Multiline Text parameters to it. We need to manage this new parameter type on its own, as long we expect to need to use the older versions of Revit.

Oh, if you manage to do this before finding out it won't work...you can open the Shared Parameter file in Notepad and delete the line that is dedicated to the Multiline Text parameter(s) you've created. It should work again in 2015 or older versions.

A comment (to a previous post) regarding this new feature alerted me to this issue, thanks Abe!

Shared Parameters are Shared Definitions

We tend to think of Shared Parameters as a thing, equal to Family and Project parameters. I've even described them as such in past posts on the subject. If I'm very picky and technical they are not a thing, they are a device, a parameter definition, shared to either create a family parameter or project parameter or both.

Yes, they help us create a Family or Project parameter, but on their own they are nothing, they only exist in a text file. That text file only defines their name and data type, nothing else. Okay technically the file has a little more data in it than that but it's only used internally by Revit. It doesn't mean they have standing or truly exist on their own. We have to apply them to Family/Project parameters for them to mean something, be something, be useful.

Written another way, a family parameter (either component or system) can be created from a shared parameter and a project parameter likewise but there are no shared parameters that aren't one or the other.

This is why I regard them as a definition stored in a dictionary, the Shared Parameter file.

Sorting Parameters - Shared Parameters and Projects

With 2015 it became possible to move parameters into more desirable positions within the properties of the family. In the family editor we see a Move Up and Move Down button to make this possible.

In projects however there are circumstances where taking the trouble to do this in the family doesn't have the same result in a project. A thread started at Autodesk's Revit Newsgroups where a product support specialist (Alaaeldin_Alsahil) responded with the following:

Shared parameters are shared between families in the project. The first family to load a shared parameter definition into the project defines the behavior of the parameter (in other words when loading a family into the project the description stored in the document is the one that is used). In this case, there was probably a family that was loaded with these parameters defined as "Other than the one from the family".

He then added:

The biggest problem is the shared parameter definition in the document cannot be edited (or deleted!) from the project. Purge unused also does not clear these definitions. There is no way for the customer to fix their file.

He suggested a workaround of creating a brand new shared parameter definition (new parameter in the shared parameter file), so that the definition in the project can be redefined. That's not always possible, in fact more than likely not acceptable either. For this project we'll have to live with the sorting condition as is. He did mention that loading content into project template files don't seem to suffer the same fate. That's good at least from a template standpoint.

Revit 2015 - Parameters and View Titles

We can include any view parameter in view titles now. We can also create shared parameters and use them in our view title annotation. I was reminded by Lee Miller (a VP with HOK), while attending RTC in Melbourne this week, that this addition means they can include another language for the view name far more easily with this seemingly subtle change. It is a welcome change for anyone doing international work.

Hidden Parameters

Hey we missed an undocumented feature in 2015! Hidden Parameters! Notice the column for Hidden in the dialog?

Maybe a product manager will see this and blink? Sorry it isn't real, it is a mock-up. Yes, it's a few days late for an April Fool's joke.

Daniel Stine and I traded a couple emails recently and part of that conversation included the concept of making parameters hidden. He passed along this image to illustrate his idea.

For background, if we edit a Shared Parameter file with a text editor, something that we are warned not to do in the opening paragraph of the file itself (see the link for Walking on Thin Ice below), we can set a value that causes a parameter to be hidden from the user when the family is loaded into a project.

This technique only works for Shared Parameters and is really only practical for loadable (component) families. You have to set the parameter to hidden BEFORE you use it AND you can't reverse your decision without removing and replacing the parameter. The parameter remains visible while editing a family. It is not visible to users in their project. By not visible I mean it does not appear in the Properties Palette or Type Properties dialog.

I think it IS desirable to have more control over user interaction with parameters. I'd like to be able to make it more obvious which parameters are for their input versus derived from other parameters. Color coding, locked, hidden, and many other ideas have all been discussed over the years. It seems to me that adding a Hidden column would be an interesting way to define how a parameter should be regarded by a project. Certainly less secretive than the existing approach.

Related Posts:
Walking on Thin Ice
Ignore Good Advice
Making Shared Parameters Hidden (from What Revit Wants)

The Case for Using Project Parameters

Project Parameters are most effective when the information stored with them has no direct geometric impact on the families and categories they are associated with. For example if you expect the information to alter a family's size it can't be a Project Parameter, it needs to be part of the family itself.

One example of a Project Parameter could be the horsepower rating for a motor. A family might get larger when its designed to provide more horsepower but that value alone seldom drives a specific dimension. A manufacturer will provide dimensional parameters for that and HP (horsepower) usually happens to increase as the capacity and physical size of the motor increases.

With this in mind, we can create a Project Parameter for horsepower it can be applied to one or several categories, such as, Mechanical Equipment, Electrical Equipment, Generic Model and others. Every family that we load into our project and belongs to one of those categories will inherit that parameter without first having to edit any families to add it manually. The project adds it to each family that is loaded for us. If we edit a family, apart from the project, the parameter doesn't exist.

This is a benefit but it also has a cost. All loaded Mechanical Equipment, for example, will inherit the parameter (Horsepower for example) even if it is irrelevant to some of the mechanical equipment families. Generally the benefit outweighs the cost though.

A Project Parameter can be created isolated within a project or based on a Shared Parameter. Shared Parameters are like definitions stored in a dictionary. The Shared Parameter file (dictionary) provides a common single location to store parameter definitions we are likely to reuse. That means Project Parameters (and Family Parameters) can be created from a Shared Parameter (definition) stored in the dictionary (shared parameter file) or just created and stored in an individual project.

Whenever we want to create a parameter in families and/or projects AND apply a tag to display the same parameter value and/or include it within a schedule we must create and use a Shared Parameter. If you'd like to read older posts about parameters check out my SUMMARY POST.

Family Editor Thought and Tips

There are many great ideas for improving the family editor experience "out there" already. Here's another thought prompted by some Shared Parameter loading.

When you first enter the Parameter Properties dialog, after clicking the Add button, the radio button for Family Parameter is selected and the Select button is disabled.

Seems to me the button could be enabled. This would allow me to click on the button to select a shared parameter without having to first change the radio button selection to Shared Parameter instead. It's just one click different but if you load a series of shared parameters repeatedly now and then one less click is one less x number of parameters involved.

Seems reasonable to me...now for a couple tips.

Here's a little data entry tip in the Formula field, click past the value to select everything faster. If you click "on" part of the formula entry the cursor lands there. If you click past it looks more like this.

If you click on the formula then it ends up like this.

Once you click in the field the "tip" is "off", you have to click elsewhere (outside the field) before it will work that way again. If you are already in the field the Home and End buttons work nicely to move to the beginning or end of the formula. I find CTRL + A (select All) doesn't work there so I tap Home and then Shift + End to select the whole line. Then again I don't usually do that at all, I use my tip and click past the text. You can also select all the text (in the value or formula column) if you are careful to left click on the field and then drag your cursor out of the field before you let go of your mouse button.

Okay, one more really subtle one, as if that wasn't subtle. Ever notice how the information in the family types dialog can "jump" when you click in a field, like in the formula column? That happens when the column is wider than what the dialog can display. Easy to fix, just squeeze that column so it's entirely visible and Revit won't jump (scroll over to the right usually is what I mean by "jumping").

Shared Parameters aka Dictionary

A Shared Parameter is like a definition and the Shared Parameter file is like a dictionary.

Consider that a family parameter is confined to a family. It can be seen from within a project but not scheduled or tagged unless it is a built in parameter like those listed under the Identity group (and provided for us by Autodesk).

Consider that a Project Parameter is part of a project and applied to categories of families so that it can be scheduled, but NOT tagged. Like a Family parameter it is "trapped" there, in the project.

A shared parameter bridges both trapped conditions, acting as a definition we look up in a dictionary (the shared parameter file). We store our common definitions there so they can be applied in other projects or families. When you create a family or project parameter using a shared parameter (definition from the dictionary) it is really just another parameter but it has expanded possibilities because it is "shared", the data stored with it can be scheduled AND tagged.

Parameter Related Post Summary

Updated May 30, 2017

Posts from 2005

(2005) What are parameters and why should I care?
(2005) Sharing Parameters - An Overview
(2005) Shared Parameters - Part 3
(2005) Shared Parameters - Part 4
(2005) Making a Shared Parameter File
(2005) When is an Instance really a Type?
(2005) Ignore Good Advice

Posts from 2006-2008

(2006) Walking on Thin Ice
(2007) Family Editor - Parameter Order
(2008) Duct Size Parameter - Inches - Revit MEP
(2008) Dept. of Subtle - Filter Parameter in Tags (really subtle)
(2008) Shared Parameter File - A Little Clarification
(2008) Shared Parameter - No you Can't -Yes you Can

Posts from 2009

(2009) The Order of Parameters - Revisited
(2009) Titleblock Parameters
(2009) Which Group? Choosing a Parameter's Parameter
(2009) Revit Family Style Guide
(2009) Titleblock Parameters
(2009) Dept. of Subtle - Family Editor Parameter and Formula
(2009) Back to Basics: Mark and Type Mark
(2009) Dept. of Subtle - Three Parameter Tips?
(2009) Revit API SDK - AutoParameter

Posts from 2010

(2010) Export a Shared Parameter
(2010) BIM Family Toolkit at Autodesk Labs
(2010) Dept. of Subtle - Parameter Shuffling
(2010) Family Editor - Use a Default Type
(2010) Dept. of Subtle - Omni Class Parameters Missing

Posts from 2011

(2011) Parameters Again
(2011) Parameters Again
(2011) Dept. of Subtle - Family Editor Parameter Lock
(2011) Dept. of Echo - Type Catalog Formatting
(2011) Dept. of Echo - Shared Parameters for Manufacturer
(2011) Family Type Parameter Gotcha
(2011) Revit Content Standards - ANZRS
(2011) Dept. of Subtle - Connectors and Diameter
(2011) No Math Characters in Parameter Names
(2011) Family Category and Parameter Dialog
(2011) Shared Parameter Utility - Revit SP Writer

Posts from 2012

(2012) Connecting Parameters
(2012) Connecting Parameters in Nested Families
(2012) Pushing Parameters Around
(2012) Parameter Grouping
(2012) Shared Parameter Article at AEC Bytes
(2012) The Shared Parameter File has no Relationships
(2012) A Small Collection of Family Editor Advice
(2012) Parameter Pecking Order or Priority
(2012) Shared Parameter Czar
(2012) Which Overwrite is Right
(2012) Shared Parameters aka Dictionary

Posts from 2013

(2013) Working with Type Catalogs
(2013) Associate Family Parameter

Posts from 2014

(2014) Visible Parameter and Associate Family Parameter
(2014) A Case for Project Parameters
(2014) Hidden Parameters
(2014) Parameters with Math Characters
(2014) Setting Yes No Parameters with Formulas

Posts from 2017

(2017) Recover or Acquire a Shared Parameter

Connecting Parameters

You've just downloaded some content from a manufacturer's site and realize that none (or many) of its most interesting parameters are not going to show up in your schedule. This is due to the lack of a common shared dictionary of parameters that we can all rely on. Revit's "system" parameters like Width and Height for some components (like Doors or Windows) just work automatically. Just starting out with a door template means that at least a couple parameters will work without any extra effort. Not true for enough others though.

The Autodesk Family Style Guide (AFSG) while primarily focused on the needs of Autodesk's Seek site also provides a set of shared parameters we can all use (check out ANZRS too). It's weakness is relevance and timeliness. It has a lot of MEP related parameters but doesn't delve into other disciplines seriously and it's really late to the table. Most of the firms that have been using Revit seriously have already dug into their own shared parameters by now. Redoing their library to be in line with Seek and the AFSG doesn't actually begin to help them unless they really start using a lot of Seek content, which is another can of worms.

Rather than continuing to lament the situation this post is intended to provide one solution to getting "foreign" content to work within your existing project(s) and template(s). Assuming you've already mapped out your own shared parameter strategy you just need to connect the dots between the parameters the family is using and those that you wish it was referring to, your own.

It's rather simple really. Add your own Shared Parameter versions of the critical parameters in the family you are working on. For each, in the formula column enter the name of their equivalent parameter. This maps (connects the dots) their parameter value to yours.

Now you can schedule their component along side your own, even tag if necessary. It's a lot simpler than trying to remap all their parameters to your own by replacing them.

It is a little risky in that people will have two places that the values could be touched, their parameter and yours. I usually just segregate them in a separate Group. Just let your teams know how you are dealing with content obtained from other sources and it's not mysterious anymore.

Shared Parameter Article at AEC Bytes

Since I recently wrote a series of posts about them I thought I'd mention yet another source of information about them. Daniel Stine wrote an article recently for AECbytes. Check it out!

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).

Export a Shared Parameter

A more recent post with images is POSTED HERE now.

or alternate title, "Road to Recovery"

When you don't have access to the original Shared Parameter's file there are two ways to get to it, via a family or in a schedule. Either way you need to be able to “touch” the parameter so you can use the Export option for shared parameters. Revit will add the parameter to the current shared parameter file you are using.

In a family you need to open Family Types, select the parameter, choose the Modify button.

In a project schedule you need to take a look at the view properties for the schedule, view the fields, pick the parameter, then click Edit.

In either case you just need to click Export and Revit will warn you that it will add it to the current shared parameter file you are using.

 

If the Export button is not active it is because you don’t have a shared parameter file selected yet. You’ll need to do so first. Go to the Manage Ribbon > Settings panel > Shared Parameters button, browse to find it or create one from scratch.

The only family type that doesn't play along with this scenario is titleblocks. Shared parameters that are used in titleblocks must be "connected" to a project by adding the shared parameter to the project as a project parameter too, since titleblocks are sort of a "tag" for views.

Parameter Pecking Order or Priority

There is no preference applied to one over another. A Shared Parameter is no different than a Project Parameter... a parameter is a parameter. How they are defined and shared between projects and families is different.

A family parameter is confined to the family. It can be seen and altered from within a project but not scheduled or tagged unless it is a built in parameter (created by Autodesk's Revit team) like those listed under the Identity group.

A Project Parameter is part of a project and applied broadly to a single category or even categories of families so that it can be scheduled, but not tagged.

A shared parameter bridges both, acting as a dictionary (the shared parameter file) by storing common definitions so they can be reused (yes "shared") in other projects or families. When you add a family or project parameter using a shared parameter (definition from the dictionary) it is really just another parameter but it has expanded possibilities because it is "shared".

If you add a family parameter to a door called "My Parameter" and add another Project Parameter to your project called "My Parameter" (applied to door category) and create a Shared Parameter (added to door and project) called "My Parameter" you'll end up with four (4) parameters called "My Parameter" in the project. All will be listed in the properties of the door family in the project. A couple will be listed in the door family itself when open in the family editor. A couple will be available in the Schedule Properties dialog. The name we "see" for a parameter isn't really what makes it unique. They have a GUID (globally unique Identifier).

Short answer...doesn't matter how you add the parameter, Revit doesn't pay more attention to one over another or deal with one kind first, then another...no pecking order.

Shared Parameter Czar

I encourage people to have a single point of contact (POC) with Shared Parameters. If a project needs a new parameter then see the POC for getting it added to the office Shared Parameters. Often this interaction makes a team aware of the fact that such a parameter exists or a similar one does for much the same purpose. Same goes for firms with more than one office. They just need to share a read only copy of the shared parameter file for each office so they can use them too. Call the POC the SP Czar or King or Gov... put one person who has the best handle on what exists and what's possible and what it's all about... Alfie.

If you have job or client specific sets of parameters, just create a separate group for them. Avoid having job specific things for generic things like length, width etc. Often this starts with documentation requirements, what has to appear in a schedule for example. If you and the office can define what information must appear in that kind of documentation you can map out a parameter strategy. Keep in mind that this situation is happening in every office and for every person that makes content... I think of it as the great big can o' worms that Revit and BIM have spun the lid off and hasn't resolved.

The Shared Parameter File has no Relationships

I frequently read about or hear questions about this concept that generally assume or expect that there is some inherent (permanent or connected) relationship between a shared parameter file and the use of such a parameter in a project or family.

The shared parameter file has no active relationship (no link, no "xref", no lookup) with your families or projects so there is no risk of someone running off with it, or it getting deleted. The shared parameter file is only used like a "dictionary". We/Revit uses it to "look up" a parameter definition to apply it to a family or project. Thereafter when Revit encounters it in the project it knows what it means. Thus no active connection to the parameter in the file itself.

If someone loses the shared parameter file it is possible to export shared parameters from projects that have them to restore their definition to a new "dictionary". You can read this post to find out how.

Room Name Alternates

This is a repost of one I wrote back in December 2008. It came up again recently in a question via email and I noticed it's a pretty old post so I thought I'd plug it again.

Sometimes a name is just too much, too long, it just doesn't fit in a room. The stock Name parameter for a room is easy, it's already there waiting for us to us. When we use abbreviations in this parameter we end up with some full names and some abbreviations. An abbreviation of "T." for Toilet might be fine on a plan view but it is less than stellar in a schedule. We could use another stock parameter like comments to store an abbreviation instead but that subverts its usefulness for actual comments.

Shared Parameters to the rescue!

I've written several posts about shared parameters in the past so I won't go into making them again in this post (see bottom). This is what you need to do to get a new parameter working in a project.

Create a shared parameter (called Abbreviation for example)

Create a room tag family that uses your shared parameter, save the Family and load the family into your project

Add a Project Parameter (Settings > Project Parameter) using your shared parameter too. Assign the parameter to the Room Category

Use the parameter in your rooms, set-up a schedule and tag your rooms with the appropriate tag.

This gives the best of both worlds. Supply abbreviations for names that are unruly and don't bother for reasonable names. A schedule will make it easy to define either and those that don't have abbreviations don't "need" them. Just make sure you use the correct tag to display the value you really want people to see. You could also use this technique to provide a room name in a second language, if necessary.

I've posted a revised copy of my Egress Example project that contains a working example of the shared parameter, tag and schedule.

This post Shared Parameter File: A Little Clarification provides a full list of the posts I've made in the past on the subject of Shared Parameters.