Mystical SharedParameterElements

[gprofile]

I have been looking at the ShareParameterElements behaviour in the project for quite sometime. There are few things which are still not quite clear to me.

Shared Parameter in the text file lets call it - SP. This Shared Parameter(SP) created in the Family and Project lets call it as SPF and SPP respectively.

• The SPF loaded along with the family in to the project gets in to the project and it sits in the SharedParameterElement Class of the database as shown below from SnoopDB
• The SPP when added in to the project via Manage -> ProjectParameter also sits in the SharedParameterElement Class of the database, below the picture of it from SnoopDB
• When one of these above for example SPP deleted via Manage -> ProjectParameter and SPF deleted in the Family and loaded again in to the project, ideally these should be synchronised and removed from the database. But it doesn't.

SharedParameter(SP)Adding SharedParameter to FamilyUpdated Family with SharedParameterSnooping DB before loading updated FamilySnooping DB after loading the FamilyAdding SharedParameter to the Project attaching it to door CategorySnooping DB after loading ShareParameter into the ProjectSharedParameter as seen in the Door ElementSnooping DB after deleting SharedParameter in the Project, still existing in the DBSnooping DB after deleting SharedParameter in the Family and reloading it in the Project, still existing in the DB

And my question goes is: How could one remove/purge these dormant parameters from the database? How could we separate these parameters from the ones not used and used or specifically how could we know if these parameters, in case of SPF are linked to any Families or SPP are attached to any Categories in the project before removing them?

[MarryTookMyCoffe]

You can't remove them, the only thing you can do, is check if the element is bind. This sucks, I know.
Working on sheared parameter will give you a lot of trouble, there is so much mess in them.
My suggestion is to never ever try to make them dynamic, set on one design  of shared parameter(set one GUID for one name and never change it) and just make sure that they are bind in right way.

In theory you can close document and open it again but that is super bad idea.

Two years ago I was frustrated with SP and lately I had to go back to them just to discover why I was So angry in past :D. They really miss SOLID shot there.

[gprofile]

@MarryTookMyCoffe Apologies for my late reply.

Now I understand the frustration is not only with in me. Most of the time I try to keep or maintian SP to be fixed through out the project life cycle but some parameters do need experiments and it really is bad when the dead ones stay. Its the same with the object styles all those unused sub categories stay even though they aren't bound to any elements anymore.

One quick question here, is there way to check if the Shared Parameters are bound to any elements so I can programatically delete them if they aren't. I collect all the shared parameters in the documents like this

var fec = new RevDB.FilteredElementCollector(doc)
.OfClass(typeof(SharedParameterElement)).Cast<SharedParameterElement>();

How could i check if its binded or not? and delete them using

var del = doc.Delete(elementId);

[MarryTookMyCoffe · Accepted solution]

here is part of code

  BindingMap bindingMap = document.ParameterBindings;


            if (!bindingMap.Contains(sharedParameterElement.GetDefinition()))

look in to sdk, for more:
https://www.revitapidocs.com/2017.1/4ce777fb-ab30-6d15-d019-5b430223ac62.htm

[felipse]

Hi,

Sorry about ressurrecting this post, but I was wondering if you managed to write a code that works?

I have a similar issue where I wanted to identify if the ghost shared parameters I found on my project are associated to any objects/families + identify the specific objects/families so I can check if they're useful or not...

I'm not really familiar with bindings but I've seen some dynamo nodes with embedded python code which use them to manipulate the project shared parameters.

Thanks in advance!

[MarryTookMyCoffe]

it usually take autodesk 5 years to fix minor problems, but it is cute you have hope.
The clear answer would be to be able to create project parameter in revit, but for them to do anything, there has to be a mob under a window.
Try vote on idea, maybe after 3 years they will do it.
https://forums.autodesk.com/t5/revit-ideas/add-revit-api-support-for-non-shared-project-parameters/i...
https://forums.autodesk.com/t5/revit-ideas/expose-project-parameters-to-revit-api/idi-p/10703459

from what I seen in updates, I don't thing they add anything new, but who knows maybe I miss some thing. For now we are stuck with what we got.
It is ok to resurrecting post. Sometimes it shames them to make corrections.