@jacob.small - Link-back to original topic: Delete unused shared parameters?
Here is an example of the Zombie Parameters ; ) Images inside file as well for reference in a fres no-template file fully purged… R23*
Zombie-Parameters-Example.rvt (800 KB)
This has been a long-standing issue in Revit : (
Started by adding parameters
and another:
Then delete:
Snoop-
Deleted parameter:
And the other parameter for reference:
If we could run a DYN player or a PyRevit or have Autodesk fix the issue that would be fantastic.
@SeanP - repost from other thread if you have suggestions as well.
Snoop it before/after deletion. Is there any parameter that changes to indicate its in the model but ‘deleted’? If so that could be used to delete zombie parameters only from all the SharedParameterElements potentially.
1 Like
Still not sure I see the issue… "There is data in the file which is only visible to users via the API isn’t a problem or bug. IT’s actually qutie common and required for file stability. I guess they could swap the name…
What is the problem presented by having these extra parameter elements in the file? On a scale of 1 to 10 where 1 is “a handful of BIM managers who’ve found how to identify these exist” and 10 is every single Revit user globally, how many are impacted by this, and how so?
Even without seeing the issue, this appears to be pretty simple to do.
The parameters in use by the project parameters can be pulled using the ParameterBindings property of the document. The shared parameters elements can be collected by filtered element collector, which allow pulling the definition with the GetDefinition() method. The binding map can be checked to see if it contains the definition with the Contains() method. If that contain test wasn’t true, you can delete the object from the document with the Delete() method of the document. Otherwise you can move on.
Overall it looks something like this:
import clr
# Import DocumentManager and TransactionManager
clr.AddReference("RevitServices")
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager
# Import relevant sections of the RevitAPI
clr.AddReference("RevitAPI")
from Autodesk.Revit.DB import Document, SharedParameterElement, FilteredElementCollector
doc = DocumentManager.Instance.CurrentDBDocument #the active document
TransactionManager.Instance.EnsureInTransaction(doc)# Start Transaction
bindings = doc.ParameterBindings #get all the parameter bindings in the document
sharedParameters = FilteredElementCollector( doc ).OfClass(SharedParameterElement).ToElements() #get all shared parameters in the document
results = [] #an empty list for our results
for sp in sharedParameters: #for eveyr shared parameter perfor the following
spDef = sp.GetDefinition() #get the definition of the shared parameter
test = bindings.Contains(spDef) #test if hte bindings map contains the defintion
name = sp.Name #get the name of the shared paramter
if not test: #if the definition was not in the bindings map
doc.Delete(sp.Id) #delete the shared parameter
results.append("Shared Parameter {0} was deleted.".format(name)) #let us know the parameter has been deleted
else:
results.append("Shared Parameter {0} is in use.".format(name)) #let us know the parameter is in use
TransactionManager.Instance.TransactionTaskDone()# End Transaction
OUT = results #return the results to Dyanmo environment
Note this won’t check to see if it messes with your families - that’s a bigger issue and I believe why the Remove Project Parameter doesn’t go nuclear at first. I believe you’d have to open each family document 1x1 to confirm it doesn’t break something else, which is a time consuming process. Would love to hear otherwise though.
6 Likes
I think the only scenario here it impacts is if a parameter doesnt change guid but changes unit or name. Definitely a 1/10 task for sure.
Handy code! Time to make a pyrevit tool for it in my secret BIM manager tool tab…
2 Likes
Just be careful with it. I’m really cautious of adding a ‘delete’ to something that the Revit team hasn’t already automated… The Revit team usually has very good reasons for not doing so and I usually overlook that reason until I’ve fowled something up.
1 Like
I’ve done it before in the past manually so I believe it should be OK, but yeah fair point. If we cant remove it then I would have thought the team would build in an error at least surely ala trying to delete the int origin.
1 Like
Good point, but always proceed with caution. If I recall it was only a few releases back where we could delete every single view in the file, and save. Next time you open “there are no views in this file so we can’t open it” error appears.
1 Like
Works like a charm! Thanks @jacob.small !
Not sure how it got in there- might be Ideate unlocking something it shouldn’t. Tried this morning and kept getting a warning “Associate at least one element to associate with parameter” on trying to remove it.
Really helpful though for same-GUIDs with different info (Or info updates!!!)
Routine with copy-paste winform attached:
Parameter-Purge-Unused.dyn (11.7 KB)
2 Likes
