How to switch shared parameter (group parameter under) to already assigne family

[avinashmailbox]

Dear all,

Need help over shared parameter for changing its groups from already assigned values to new one.

For Ex. from the Shared parameter file we have taken "XYZ name" parameter from specific group "General" and while assigning group in Revit I have assigned to the different group other than "general".

So as per our new requirement we need to change it from other group to original one "General" group, But we are unable to do that!

Please suggest how to overcome this problem.

ASAP. 

[robert.klempau · Accepted solution]

Hello @avinashmailbox,

My Name is Robert Klempau and I am going to help you with your problem.

"Once you load a shared parameter into a project, the project keeps a copy of the definition of the parameter. When you change the category in the family, it does not override the project definition because that would affect all other families that use this shared parameter.
For example, if Family A said the parameter is in Group X and Family B said the parameter is in Group Y, the project would use the definition of the family that was loaded into the project first. Loading the second family would not change the project definition.
Parameters that are not shared do not affect other families in the project, so changing the group for those parameters works as expected; there is no project-wide definition of the parameter."

Please see: Family parameters appear under a different group than is set within the family

Note: the first family with a certain parameter under a certain Group that gets in a Revit Project defines the Group under for all the families that are loaded afterwards.

I saw this link: How to truly purge Project (Shared) Parameters

Did not read it completely but it could help.

[robert.klempau · Accepted solution]

Hello @avinashmailbox,

As you may know, if a certain shared parameter comes into your project after inserting a family and that parameter is placed under a wrong parameter Group and you insert a family with the same parameter but it is located under another group in that family, the parameter will be placed under the group that previously was defined in the project by the first family that had this shared parameter.

So what if you want to change that?

Or when you need to rename the shared parameter for some reason.

Well, you need to remove that shared parameter from your project.

So first you have to remove all the families from that project that have that parameter. 

Then remove the shared parameter from the project parameter list if it was if added there.

Now you think you're done? 

Unfortunately not. 

The shared parameter is still in the background of your project but you can't get to it with Revit OODB.

What you need is a small tool from Jeremy Tammik called Revit Lookup.

Just see RevitLookup for Revit 2017 is here! or RevitLookup for Revit 2016 is here!  and get the Add-in.

Below you see a screencast where I show you how I used it to remove a shared parameter from my project.

You can use the same method to remove a shared parameter from a family. 

Important note: If you have families in your project that have not been removed and the shared parameter is removed from the project, also the parameter is removed from the family. You will see that when you open the family.

If a shared parameter is used in formula's or connected to dimensions, this action can break your families.

So be very sure what you are doing when you use this method.

[avinashmailbox]

HI Robert, We appreciate your solution but we found another easy solution which we will like to share with you hope this will help! Step 1. Load the same parameter from the shared parameter file as a project parameter and assigned it to the required group. Step 2. Removed the added parameter from the project parameter. You will find the parameter is already assigned to req. group. If you want more details just let me know i'll share it with you. If my post answers your question, please click the "Accept as Solution" button. This helps everyone find answers more quickly!

[amila_sabic]

View>schedules>on Panel Schedule select parameter you want to edit.
Click Edit, change Group.

[Anonymous]

It is worth noting that this undesirable effect can stem from schedules as well as families. Suppose I create a "Doors" Schedule and add to it a shared parameter "Width" in doing so I will select a parameter grouping, "Constraints" for example. Then I load a Window family with the same shared parameter "Width" grouped under "Dimensions." In the family environment for that window family I'll see "Width" under "Dimensions" but in the project environment it will be grouped under "Constraints." This will happen occur even if I delete that schedule before loading in the family. In either case, changing the grouping within the schedule will resolve the issue.

[dhelling]

I have tried to seek out a solution to this as well and I have yet to find something great. 

For context, I typically edit all my master families from an editing project.  This gives me a project environment to test my master families and also provides a backup of families in the event another user overrides the master families by mistake. 

Like mentioned in someone's earlier post, I can create a shared project parameter and re-assign the group there, but this doesn't always work.  With some families I sometimes get two parameters of the same type and name but located under two different grouped locations (see picture below).  I am not exactly sure why this happens but my hunch is that since the project keeps an ID# of each shared parameter, this can get messy when a shared parameter is deleted from the txt file but then added back.  Reminder, whenever you delete a shared parameter from its shared parameter txt file, you will receive a warning like shown in the second picture below.  This makes me believe that the old shared parameter is still recognized in families and project parameters that already exist, but when a newer family or project gets a recreated parameter of the same name and type, the recreated parameter will likely have different ID# than the original shared parameter.  Thus I wonder if this is why I can sometimes get two parameters of the same name and type but located under two different groups.  So I guess my solutions/conclusions are to replace the shared parameter with a completely new named parameter so that its a new parameter presented to the project OR delete all the families from the project and use that Revit lookup addin (or something like it) to wipe out the projects shared parameter settings (and then reload the families).

Wow Autodesk, you sure made this confusing!  I hope someone else comes up with easier/quicker solutions.  

Thanks,

Dan

[fabiosato]

Hello,

You figured out your problem, the Shared Parameter is defined by its name and the GUID, if the GUID changes, Revit considers it another parameter.

[chauh]

This was very helpful. Please note that you do not have to purge out the family from your project before doing this in my testing. You can still select the parameter by its ID and then delete it, load your family, and then you are off to the races. This should save you the headache of replacing all of the objects in your project.

[nejcbh]

This procedure works like a charm! This should be the chosen solution of this question.

[djthompson]

The solution I use is this.

Load the families for a particular category into a project.

Create a Schedule for that Category. Add the Shared Parameters in preferred order to that schedule that you want to organise. Edit the Parameters in the schedule and assign the correct Groups.

This last step is important. Save back the Families to disk.

Now you have your Families corrected and the Project.

This has always seemed like a limitation to me. I might for instance have a family with "BOX WIDTH" in Constrains because it is at the top of the properties for user facing input. Then I have "BOX WIDTH" in another family where it is formula or Type driven, I don't want this in Constraints in the Properties pallet because the user has no input.

I don't think this is an issue for Family Parameters because they only exist in that family and there groups are respected.

[bruno3UP3U]

this is it!