FabricationParts not taking Shared Parameters

[Anonymous]

I have a protocol to place shared parameters on a variety of Element types, including FabricationParts:

string sDataDirectory = AppDomain.CurrentDomain.GetData("DataDirectory") as string;
pApp.SharedParametersFilename = sDataDirectory + @"/MyPlugin_SharedParameters.txt";
var pParams = pApp.OpenSharedParameterFile();

// Pipes
var pPipeGroup = pParams.Groups.get_Item("Pipe");
var pPipeCategory = pApp.Create.NewCategorySet();
pPipeCategory.Insert(pDoc.Settings.Categories.get_Item(BuiltInCategory.OST_PipeCurves));
pPipeCategory.Insert(pDoc.Settings.Categories.get_Item(BuiltInCategory.OST_FlexPipeCurves));
#if !RV2016
    pPipeCategory.Insert(pDoc.Settings.Categories.get_Item(BuiltInCategory.OST_FabricationPipework));
#endif
var iPipeBinding = pApp.Create.NewInstanceBinding(pPipeCategory);

using (Transaction pTrans = new Transaction(pDoc, "Set Parameters"))
{
    pTrans.Start();
    foreach (var pDef in pFabProGroup.Definitions)
        pDoc.ParameterBindings.Insert(pDef, iFPBinding, BuiltInParameterGroup.PG_IDENTITY_DATA);
    pTrans.Commit();
}

My testing model using FabricationParts of the type FabricationPipework will apply other parameters to other Categories, but not the FabricationPipework...  Any ideas?

[RPTHOMAS108]

The segment of code is a little confusing because it isn't a full picture i.e. you open a shared parameter file at the top of the example but you don't use it for anything i.e. where is pPipeGroup used in the example? You create a binding iPipeBinding which you don't use in the example transaction either? The binding you are using in the transaction iFBinding comes from somewhere else above? Note that external definitions become invalid if the shared parameter file they came from is no longer in scope.

There is no issue adding shared parameters to the Fabrication Pipework category within the UI so there shouldn't be within the API (although stranger things have happened).

[Anonymous]

Hi RPTHOMAS108,

Per the code above, pParams is the Shared Parameter file, and it never loses scope.  I use it to grab the Parameter definitions for the Groups.  I did not include all the code for the function because it's a bit repetitive.  I do the same thing for multiple categories.  pPipeGroup is used in the foreach loop, looking at the definitions of the parameters in the category, and applying them.  I mixed up some of the parts of the overall method in my example.  In the foreach loop, sub out pFabGroup for pPipeGroup and iFPBinding for iPipeBinding.  

This method has worked for me for years.  The only thing it doesn't seem to be working on is FabricationParts; rather it only will apply to certain types of FabricationParts.  I've stepped through the code and it seems to be working for some and not others.

Is there a process (that you know of) different than that I'm doing which you need to implement Shared Parameters to FabricationParts? 

[RPTHOMAS108]

Any exception information or does it just fail to add the parameter, if so is an exception being caught higher up?

Try doing the same manually in UI to verify parameter can be bound, also worth taking a cut down version of the code out and run it in isolation from the rest of the code i.e. the minimum of what you need to bind a parameter of that type. 

[Anonymous]

It's not hitting any exceptions - it's just failing to add the parameter.  Now here's the weird thing:  It's adding the parameters to new Elements, just not existing ones...

I've already encountered a problem where some shared parameters are being duplicated because I've changed their categories in the file, and then when I go to set the parameter, it doesn't know which one to set, so it sets neither...  But that's not what I'm dealing with now...

The new, updated, problem is that existing Elements are not receiving the parameters.  Could this have anything to do with permissions as they pertain to editing a centralized or detached model? 

[RPTHOMAS108 · Accepted solution]

From memory if it's been bound previously you need to call reinsert (even if it has been removed).

I can't recall the exact details of this.

There is a certain order of API calls in terms of Insert and ReInsert, so that you don't need to worry about previous state. Always found that remove didn't remove them completely and ReInsert only works if they already exist.

[Anonymous]

Yea...  I pretty much just revert the model to it's original version (before I started testing on it) when that's needed.

Any ideas on why the parameters would be applied to existing Elements, but will be on new Elements?  Them being on the new ones confirms that it's working, at least in part.  On other existing parts, like standard Pipes and FamilyInstances seem to be getting the parameters in other models I test on...

[bruno.rochaBRBQ5]

Any reason everyday when I create my local file all my shared parameters options are uncheck just for the fabrication parts.

[Anonymous]

Hi Bruno, 

Your question seems a little vague. 

1. Are you referring to a Revit model (.rvt file) or a Shared Parameters file (.txt file) when you talk about your "local file". 
2. Are you working with the Revit API and applying the parameters programmatically?
3. If the answer to #1 is:
• A Revit model - sounds like the values are just being initialized to their defaults
• A Shared Parameters file - Are you creating it every time you create a new model?

Please elaborate on your question so we can better assist you.

Don't forget to mark your answers...  It helps the next individual find theirs faster!!

Cheers, 

Geoff Overfield

Lead Software Engineer

FabPro, LLC